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SUMMARY 

This report of the findings of an interdisciplinary group of research 
workers at Syracuse University deals with project management in NASA's 
Apollo program in four interrelated sections following the introductory 
chapter. 

Chapter II examines the Apollo program in the context of the total 
NASA organization. Because of its importance, Apollo tended to be the 
dominant agency consideration for several years, and as a result, the 
continued existence of NASA as a large agency was threatened as that 
program began to phase out. The Apollo program was a unique undertaking. 

As such, organizational arrangements worked out during the course of the 
program's existence must be treated as suggestive of techniques that might 
apply in other organizational settings. 

Within the Apollo program, the initial organization and its consequent 
changes proved to be influenced by various factors including the past history 
of the constituent parts of the effort, the national climate at the time 
the original decision to activate Apollo was made, the life-cycle nature of 
projects, the personalities and experience of people who were running the 
program, and the trade-offs effected which were particularly constrained by 
a tight schedule. Three significant organizational techniques that developed 
in Apollo are discussed. These are: the purposeful use of conflict to insure 
control by the top of the organisation, the use of the change control panel© 
to facilitate problem solving and coordination s and the use of matrix organi- 
zations coupled with a single authority nexus to insure continued functioning 
of the matrix. 













Chapter III of this report deals with the nature of project management 
and the manner in which project managers functioned in the Apollo program. 

There were a number of important managerial characteristics associated 
with Apollo project management methods. First, the form of project manage- 
ment used in Apollo was a problem-oriented approach. As such, its unique 
contribution to its larger "host” organization was to solve the complex 
organizational problems undertaken in accomplishing Apollo objectives. Second, 
the project management system used in Apollo was characterised by a multi- 
disciplinary management approach because complex task resolution required the 
integrated efforts of many disciplinary specialists. In other words, in 
Apollo, project management provided the vehicle for the integration of organi- 
zational specialists with the complex problems undertaken. Third, the project 
management systems employed in Apollo were designed to provide the all- 
important responsibility point-of-commitment since one manager was ultimately 
charged with the success or failure of a task. Fourth, the project approach 
used employed a systems perspective in problem-solving. Not only did the 
project manager have to be aware of the Internal workings of the project, 
he also had to be cognizant of the project’s larger environmental context. 
Fifth, project management allowed flexibility and innovation in organiza- 
tional design. This was often accomplished without a complete revamping 
of the entire structure of the NASA organization. This was evident in the 
major NASA centers whose functional organizations could be kept intact 
despite the size of the Apollo program. 

Conflict was often a fundamental characteristic of Apollo project 
management. The value of the conflict produced depended upon how the 


project team members perceived the conflict and how the project manager 
was able to manage the emergent conflict situations. Several examples 
are given in Chapter III of how conflict situations were handled by 
project participants in the Apollo program. 

An examination of the influence styles by which project managers in 
Apollo were able to get compliance from interfaces focused on four primary 
sources of Influence: reward power, punishment power, expert power, and 
referent power. It appeared that the most effective "management style" 

i T . 

employed was one based on the project manager's expert and referent power. 
Moreover, the expert /referent style would seem to be less disruptive to 
the total organization. 

Finally, four areas which produced problems for project managers in 
their day-to-day management activities were revealed. These were: managing 
human interrelationships in the project organization, maintaining a balance 
between technical and managerial project functions, coping with various 
types of project risks, and surviving institutional restraints and 
rigidities placed on the project organization. 

The existence of a very extensive technical competence within NASA 
at the beginning of the Apollo program played a large role in shaping the 
management schemes used at the three major centers involved . Chapter IV 
of this report discusses the utilization df the in-house technical competence 
in the support of the Apollo program. Organizational diagrams for MSFC, 

MSC» and KSC are presented in such a way as to illustrate the relationships 
at each of the three centers between the Apollo program offices and the 


functional directorates . 


A significant difference between MSFC and MSC is found in the location 
of sub-eystem managers in the Program Management side of the house at. the 
former and within the functional directorates at the latter. This fostered 
resentments between the Research and Development Laboratories and the project 
managers at MSFC, though it did give the managers more direct control over 
details. The sub-system managers at MSC maintained better relationships 
with their technical bases and were exposed to less professional risk in 
assuming a management position, but project managers felt a lack of direct 
communication as a result. 

Responsibility for Apollo was purposely diffused at MSFC so that center 
management was necessarily involved, whereas it was possible at-.MSC.-to ignore 
the center organization to the detriment of the program unless the ASPO 
manager specifically made an effort to involve the center. At KSC, Launch 
Operations had prime responsibility for launch and the Apollo offices served 
essentially as liason to the other two centers. The styles of operation of 
those two centers were reflected in their response to problems at KSC where 
MSC displayed a greater trust than did MSFC in its resident managers and 
contractors . 

The problem of communication and. control over changes in this tremendous 
program involving Headquarters and the three centers was very effectively met 
through the use of Change Control Boards and Configuration Control Panels at 
all management levels. These may represent the greatest contribution to 
complex project management made by NASA and the Apollo program. 

It is doubtful whether any internal management scheme, no matter how 
well conceived or carefully executed, could have achieved the ambitious goals 
of the Apollo program without the tremendous personal dedication of essentially 
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every team member to the clearly defined goals of the program. It is also 
doubtful whether success could have been achieved if NASA had not maintained 
its own tremendous in-house technical capability. Nowhere else could a 
program manager depend on such support in dealing with contractors or in 
searching for the best in alternative proposals. 

Chapter V of this report, discusses the formal and informal relation- 
ships between Apollo managers and the contractors. The project managers 
dealt with their prime contractors formally through the project or contract 
officer and the resident NASA office. Informally, a great deal of communica- 
tion took place between various pairs of people in NASA and in the contractor 
organisations. A compromise was necessary between the need for rapid com- 
munication and the more time consuming documentation for configuration and 
cost control. But this painstaking documentation is the only known method 
to insure control of a complex engineering system. 

The MSFC type of project/contractor interface was somewhat more cumber- 
some, but more thorough, than that of MSC. The Huntsville projects, to the 
discomfort of the contractor, seemed to benefit more from in-house expertise 
partly because of the weaker authority of the project manager. Schedule 
pressures, however, justified the easier decision making of the HSC style. 
Resident offices played a very important facilitating role for both princi- 
pals. The tendency of MSFC to by-pass the resident offices, however, 
limited the usefulness of these organizations. Contract negotiation through 
MSC was considered by contractors to be more direct and efficient than through 
MSFC where there was dual responsibility of contracts personnel to both 
institution and project. 








Contractor program organizations changed constantly in terms of 
resource competition within the Company . The authority of the program 
naturally depended on its relative magnitude. Matrix management was 
really practiced by the contractors only at a particular stage in the 
program's history. For many reasons* the probability of a contractor 
effectively integrating the activities of other prime contractors is 
rather small. These functions were executed best by NASA itself. 

The forced intimacy of a public agency with orivace corporations 
inevitably produced certain points of disagreement and irritation. 

There were valid grounds for some of the contractors' grievances per- 
taining to NASA procedures. Nevertheless, all concerned admitted (some- 
times grudgingly) that these procedures have helped more than hindered 
the achievement of program objectives while fully protecting the public 


CHAPTER l 


INTRODUCTION 

As a part of a relatively modest NASA program at Syracuse University, 
an Interdisciplinary team of faculty members and graduate students under- 
took a study of the characteristics of project management in the Apollo 
Program. The research was conceived partially in response to NASA's desire 
to make itself available as a learning laboratory in the area of large 
scale technological enterprise by a government agency. But it was also 
anticipated that an unbiased, objective investigation of project manage- 
ment practices by a group not affiliated with NASA or the federal government 
might result in some insights that very well could have evaded the eyes of 
those deeply imbedded in the NASA organization. The presumption that a 
University based research team could penetrate the NASA Manned Space Flight 
organization turned out to be quite correct. The team enjoyed from almost 
all NASA personnel contacted, an openness, a degree of cooperation, under- 
standing, and confidence that exceeded the most optimistic hopes ever 
entertained by the team. For this ready exchange of ideas, the research 
team is deeply indebted to NASA, and to those of its prime Apollo contractors 
who were visited, and who responded in a similar way. 

The complexity of the task originally defined required the team to 
constrain itself to the study of something less than the entire NASA operation, 
or even of the entire Apollo program. By virtue of the mutual interest of 
NASA and Syracuse University, the research team concentrated on the role of 
the project manager in the Apollo program. Since the term "project manager" 
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has many different interpretations in NASA and contractor usage, it 
should be noted that the type of project used as a model in the study 
is that exemplified by the LM, CSM, S-IC, S-II, and S-IVB efforts. 

Since project management is not isolated from the larger organiza- 
tional elements in NASA, nor from the prime contractors in industry, it 
was necessary to take cognizance of these considerations. Chapters j. 1 
and V contain commentary on these facets of project management. 

The make-up of the research team was guided by the requirements 
of the task, and an interest on the part of team members in inter- 
disciplinary research. There have been some changes in the membership 
of the team, but the core of the team still consists of the following 
faculty members: Professor Eugene E. Drucker of Mechanical Engineering; 

Professor William S. Pooler of the Department of Sociology; Professor 
David L. Wi lemon of the School of Management; and Professor Bernard D. 
Wood of Mechanical Engineering. As a by-product of the investigation, 
a good deal was learned about the interdisciplinary mode of research, 
and fed back into the operation. As a result the research group has 
become & close-knit, smoothly operating unit, contrary to the large 
number of groups which have attempted to function in an interdisciplinary 
mode but have succumbed to the many pitfalls which are known to exist. 

The information oh which this report is based was gathered by well 
over 200 intensive field interviews, almost always attended by more than 
one person from the team and usually from different disciplines. The 
interviews were usually tape recorded, transcribed, and submitted to 
interviewers for corrections. Above all, the interviews have remained 







confidential, as guaranteed by the interviewers* NASA personnel at 
several levels at the three major field centers and headquarters were 
interviewed, as well as engineers and managers at the plants of five 
prime contractors, NASA resident people* Congressmen and Congressional 
committee staff members . A comprehensive list of interviewees appears 
as Appendix A. 

During the course of the research, a three day conference was held 
with team members and various NASA interviewees in attendance. The 
purpose was to informally discuss and offer criticism of some of the 
preliminary hypotheses and conclusions. The remarks of the NASA repre- 
sentatives were extremely helpful in this regard, and many are to be 
found incorporated in this final report. 

From the various sources, and additional documentation of many 
types, the research team formed a comprehensive picture of the various 
interactions of a project manager with the elements of his working environ- 
ment. In a somewhat arbitrary manner, the presentation of this picture is 
arranged in four chapters. Although each was written by one team member, 
all chapters have undergone a detailed and critical examination by the 
other three team members. 

In addition to contributions by the project manager group to the 
Semi-Annual Reports of the Syracuse/NASA Program, various papers, reports, 
theses, and articles have been written in conjunction with the research. 
These are listed in Appendix B. 
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CHAPTER II 


A. INTRODUCTION 

The common theme underlying all of the work of the group has been 
the "project manager." Initial research quickly indicated that what he 
does cart best be understood in th- context of a series of overlapping 
organizational environments of increasingly larger scope within which 
his actions take place. It will be the purpose of this chapter of the 
report to describe and analyze the background and larger organizational 
factors which we have found to be related to the modes of project manage- 
ment adopted in the Apollo project. As well, some attention will be paid 
to the nature of the relationship between the form of project management 
and the environmental context. One unifying thread which ties together 
the points made in the discussion is the tentative idea that the organiza- 
tional change processes exhibited by NASA and the Apollo program were a 
consequence of two salient dilemmas. First, NASA had to cope with a con- 
stantly shifting environment, changing through time from supportive to 
neutral to mildly hostile. Second, NASA also had to cope with the problem 
of combining a permanent bureau organization characterized by semi- 
autonomous technical research laboratories with a large, non-permanent 

program organization characterized by highly coordinated "contract monitor- 
ing" activities. 

Before examinln&.in greater detail the nature of these dilemmas and 
the resultant adaptive organizational forms, a few introductory remarks about 
the nature of modern organizations and an appropriate model one might 
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utilize to explain their pattern of development seems appropriate. 
Basically, all organizations have two problems to cope with if they 
are to survive. First, to do something, that is, goal-oriented activity 
to provide the raison d*etre for the organization; and second, to estab- 
lish a context which facilitates the goal-oriented activity, that is, 
maintenance activity. It is necessary, of course, for these two sets of 
activities to be coordinated. 

Typically in advanced societies, the form organization takes is one 
where increasingly the goal-oriented or task activities are more clearly 
separated from the maintenance or administrative activities. This is 
partly a consequence of the complex technology generated in urban- 
industrial societies. Complex tasks that require skill levels and pat- 
terns of coordinated activities which are highly variable in magnitude- 
and duration can be conceived of and acted on in organized contexts. In 
a sense, organizational forms in advanced societies have been developing 

in such a manner as to lead to the creation of organizations within 

1 

existing organizations. Accompanying this pattern of development has 
been the attempt to exercise control by parallel forms of management to 
provide adequate direction and integration in the increasingly differentia- 
ted organizations. 

A general assussption underlying most attempts to analyse large scale 
organisation is that the character of the patterning of relationships is 
at least quasi-detenainate. That is, given a set of conditions involving 

H’he Mission Control organization within the Apollo organization is an 
example of this. 


among other things, the nature of the task activities, the state of the 
arts, the nature of the environment , the nature of the people involved, 
the past "history" of the organization, and current structure of the 
organization, one can predict the probable future states of the organ!” 
zation. This I repeat is an assumption, but it provides the basis for 
a strategy in attempting to discover the particular pattern of develop- 
ment of the organization under investigation and what is generalizable 
about that pattern, that is, what might apply to organizations in general. 

An implication of what has been said thus far is that one must proceed 
from the particular to the general, inductively, but at the same time one 
must continually build approximate models of what the general appears to 
be to give direction to one's investigation of the particular. 

Matrix organizations have been developed in modern organizations which 
do not seem to fit the more traditional models of organization. In essence, 
the conception of a matrix organization is one where the work activities 
are organized around tasks or projects. These, in turn, cut across the 
existing functional-administrative activities in the organization. From 
the task or project perspective, the larger immediate organizational set- 
ting constitutes the maintenance-resource base. From the perspective of 
the organization, projects represent temporary sets 6f arrangements created 
to accomplish specific tasks. Often these arrangements are highly variable 
in scope, complexity, and duration. 

The interdependence between the task or project and the larger organize- 
1 

tion is strong. The project represents a way in which the organization is 

3 This discussion does not refer to the special case where the project 
and the organization are one and the same. 


able to get something done. The larger organization is dependent on 
project success since the project constitutes the productive activity 
sector for the total organization. Thus, while authority is delegated 
to the project, it is not given complete autonomy. The larger organiza- 
tion provides the needed resources for the project, including the process 
of legitimizing the project, and thus the project is also dependent on 
the larger organization. 

The conception of a large organization and one large project imbedded 
within it, is a special case of generic matrix organization. The general 
model supposes that there are numerous projects, with highly variable scope, 

in all different phases of maturation^ 

There are apparent tensions in the matrix form of organization. If 
one assumes that there is a finite and limited amount of organizational 
resources (men, money, skills, etc.) and organizational authority to be 
allocated, then obviously the projects are competitive. Clearly, the 
parent organization is superordinate to the project organizations. One 
of its major functions is to allocate the resources and authority in the 
organization to the projects, such that the demands of the projects are 
satisfied and the competitive tensions are minimized. As well, it is 
incumbent upon the parent organization not to allocate resources and 
authority in such a manner as to allow the projects to become super- 
ordinate to the parent organization. Projects are transitory entities, 
created for specific tasks. Their functioning must be controlled such 
that when they phase out, the parent organization is able to survive. 


Specific to the Apollo program, this introductory discussion suggests 
that one should be able to locate a set of background factors which combined 
to produce the Apollo organization within NASA. Further, the changing con- 
figuration of background factors, the inherent strains in the resulting 
organization, the tensions produced by the large and dominant Apollo program 
organization, and the life-cycle character of the program, resulted in a 
series of organizational changes in NASA and the Apollo program organization. 
Both of these considerations are relevant for understanding the nature of the 
Apollo program organization and the varieties of project organization exhibited 
therein. As well, an examination of the NASA— Apollo complex from this per- 
spective should provide insights into the general nature of project organiza- 


tions . 


B. APOLLO AS A NATIONAL COAL 


The Apollo program represented a national goal. It publicly com- 


mitted the United States, within JO years, to safely land a man on the 


moon and return him to earth. This commitment had both favorable and 


unfavorable consequences for NASA. 


The task assigned to NASA, while complex and requiring new tech- 


nologies, was well defined, in a broad sense, which is a prime requisite 


for a successful project. The performance criterion specified landing a 


man on the moon and returning him safely to earth. The schedule criterion 


specified that the task be performed before the end of the decade, 1960-1970, 


The cost, while somewhat open-ended, was estimated to be between 20 and 40 


billion dollars. The fact that the performance, schedule, and cost criteria 


were met is testimony to the exemplary nature of the organization and 


management scheme that was created for Apollo. 


Yet another favorable consequence of the national commitment war* the 


fact that the effort was relatively free from political considerations. 


This, in effect, meant that NASA was not defined as a supporter of, or a 


base of support for, either of the major political parties, and at’ least 


in the early years of the effort enjoyed bi-partisan support. Also, because 


the prestige of the United States, in terms of claiming technological super- 


iority over the world community was being tested, great importance was 


attached to the effort. As a result, NASA had little trouble recruiting 


extremely competent personnel who were strongly committed to the manned 


space project, and who were able to view the totality of the program and 
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thu 9 maintain perspective about their individual contributions. And 
finally, again particularly in the early stages of the program, financial 
resources were not constrained. 

As noted, there were some unfavorable consequences of the national 
commitment as well. NASA was not equipped to manage such a large and 
complex undertaking. One result was that NASA had to undergo a process 
of quick growth primarily in those areas directly related to the Apollo 
program. Thus the agency was in effect subordinate to the project, and 
was severely handicapped in terms of legitimating itself as a long-rterm, 
enduring agency guided by a set of general goals. Related to this is 
the fact that NASA was viewed primarily as a sophisticated, technologically 
equipped organization which would primarily be the instrumental means by 
which the national goal would be achieved. That is, NASA, through time, 
became less often regarded as a general research and development agency 
concerned with aeronautics and astronautics. Rather Apollo and NASA were 
thought of as one and the same. Because of the funding mechanism, ill fact, 
the Apollo program supported most of NASA’s activities and as a result the 
cutbacks in budgets greatly affected not only the Apollo effort but the 
total capability of the Agency. 

The specificity of the goal, particularly the time constraint of a 
decade and the commitment to public scrutiny of the project, proved to 
be troublesome. The problem was due to the necessity of "freezing- in" 
the total concept and the design of hardware as quickly as possible. 

Thus, the early research work revolved around design decisions involving 
the booster and spacecraft and these, in turn, were influenced by the mode 
chosen to launch men to the moon. By 1962-1963 lunar orbit had been decided 


upon, the concept of the Saturn V cluster of engines had been selected and 
was in preliminary fabrication and test, and the spacecraft and lunar land- 
ing vehicle had been tentatively dimensioned and designed and initial fabric- 
ation work was commencing. Once these decisions were made there was ever 
decreasing latitude to change the design of any of the parts. The lead times 
were quite long, approximately five years,. and in the interim, new techno- 
logical breakthroughs or advanced new features often had to be ignored. It 
has been noted, for example, that the Gemini spacecraft involved a much more 
sophisticated design than the Apollo spacecraft. Problems of integrating 
the major pieces of hardware with the men and the ground checkout and monitor- 
ing equipment, precluded fundamental changes in the basic design. Cost was 
not a large factor. Schedule, because of the time frame specified in the 
1961 decision, was the prime consideration. Pure and simple, Apollo was 
originally conceived of as a space spectacular to gain back the previously 
held technological world leadership the U.S. enjoyed and other considerations 
such as scientific experimentation received low priority. 

This severe time constraint is a key to understanding the organization 
and management of Apollo. First, the designs to achieve the objective were 
blocked out. Then the rest of the effort was devoted to building up, within 
NASA, an organization and management scheme which could manage the building 
and configuring of the hardware out-of-house, which could train men, and which 
could bring it all together so that the goal was achieved before the decade 
of the 70* s. Through time the degrees of freedom, in terras of Improving 
performance of each of the parts, were further constrained and management 
was more and more concerned with fitting all of the pieces together. As a 
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result, more men and resources were devoted to coordination and control, 
and new organizational structures were appended to the extant organization 
to Insure safety and to meet the schedule. 

The severe time constraint also contributed to the tendency of the 
Apollo program to dominate the host organization, NASA, which housed it. 
That is, there was a tendency for Apollo considerations to be paramount 
in NASA, and as a result it cannot be considered a typical project. While 
part of NASA, Manned Space Flight (really Apollo) formed a separate sub- 
unit of the overall organization. It was physically separated from the 
rest of NASA and yet still integrated, particularly in the sense that men 
and dollars flowed to NASA primarily through Apollo. As fervor for the 
c ’moon mission" dimmed, the binding of Manned Space Flight closer to the 
rest of NASA was attempted. This effort to make the manned -program sub- 
ordinate to the Agency was at least partly due to the fact -that the con- 
tinued survival of the Agency rested with the success of this large program, 
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C. THE APOLLO ORGANIZATION 


The Apollo organization consisted of a headquarters unit, three, major 
operating field centers, a group of contractors, and ancillary personnel 
and resources as needed. Headquarters was given overall administrative 
and resource control over the total project, and final technical authority 
was also vested there. After some preliminary organizational attempts, 
responsibility was given to the head of the Office of Manned Space Flight 
who delegated the routine running of the organization-to the Program Director 
for Apollo within the Office of Manned Space Flight. 

By 19o3 a general organizational pattern for stabilizing relationships 
between the field centers and headquarters had been worked out. The Head- 
quarters Program offices. OART, OSSA, OTDA, and OMSF were given both the 
responsibility for managing programs in their respective offices and the 
responsibility of controlling resources, primarily men and dollars, that 
the running of the programs necessitated. In effect the Program Office 
Directors then had institutional as well as program authority. To further 
strengthen their position, they were given the title Associate Administrator 
and expected to play the role of general manager for NASA in their respec- 
tive program offices, and as well, manage the particular programs. For 
OMSF this meant that the Associate Administrator both headed up the Apollo 
ptogram and was responsible for maintaining some balance between the Apollo 
program and the rest of NASA. As was noted above, the day to day running 
of the Apollo program was left to the Apollo Program Manager, Thus decisions 

made at the top of the Apollo organization could be backed up and coordinated 
with resources. 


E .$*:■ 


The three operating field centers primarily concerned with Apollo 
were tied into Headquarters in at least three different ways. First, 
the directors of the field centers were directly under the head of the 
Office of Manned Space Flight in terms of maintaining the field centers. 
Second, the Apollo Program Manager at Headquarters was linked to the 
Apollo program managers at each of the centers and used five functional 
offices: Test, Reliability and Quality Assurance, Systems Engineering, 


Program Control., and Flight Operations, to constantly monitor the progress 
1 

of the program. From the Office of Manned Space Flight then, institu- 


tional control flowed through the Center Directors to the rest of the 
center and program direction flowed through the Apollo organization at 
each of the centers. 

The third link tended to tie both of these organizations together, 
both iii terms of horizontal and vertical relationships* This link uas 
the Management Council. It was made up of the head of the Office of 
Manned Space Flight, the three center directors, and their deputies. 

Once a month the Apollo program manager was charged with gathering his 
Apollo organization together and forging a presentation which would point 
out three aspects of the program to the Management Council; the match 
between schedule and progress, the nature of any problems that arose and 
what was needed to solve them, and the projected costs and resources 


necessary. 


*The utilization of the functional offices by program people at the 
centers varied, and their effectiveness was also questionable. 
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With the Management Council mechanism all of the hierarchical levels 
of the Apollo organization were collapsed into two, the Council and the 
Program organization, and the three centers were brought together such 
that problems specific to centers and those that ranged across centers 
could be discussed and solutions arrived at. The head of the Office of 
Maimed Space Flight, who both controlled institutional resources and had 
the ultimate Apollo program authority, by using the Management Council, 
was in a position to evaluate the "fit" between program and institutional 
activities. As well, he was made aware of any problems either specific 
to Institution or program that arose as a consequence of lack of coordina- 
tion between these two elements. 

This organizational arrangement worked out for the Management Council, 
was instrumental for the success of the Apollo program and in effect pro- 
vided the necessary authority to make the matrix concept work. That is, 
the person responsible for both dimensions of the matrix, the program 
ar'-ivities and the institutional support, was in a position if necessary, 
to "force" cooperation between the dimensions of the matrix at any level., 

If one could generalize from this single Instance, it might be hypothesized 
that matrix organizations, to function properly, must be structured such 
that a single authority nexus controls all of the dimensions which comprise 
the matrix and that feedback mechanisms must be established to insure that 
the proper information is available to that authority nexus* This is not 
to imply that cooperation must be "forced". As a rule, within the Apollo 
program there was a good deal of cooperation. But when things did not 
proceed smoothly there was a back-up device that insured that problems 




could be alleviated and a smooth working organization achieved. 

To go one step further, it also might be hypothesized that one of 
the dimensions of the matrix has to be given somewhat greater authority 
than the other dimensions. With Apollo, for example, the program people 
were given final authority in terms of the schedule, cost* and performance 
criteria. This was most clear at Huntsville and Houston where the respec- 
tive program managers were given this authority. But, the system really 
worked because both of these program managers finally established very 
close xvorking relationships with the head of each center. Thus, the head 
of each center, who formally had authority over both the technical and 
program sides of the house, could be brought in to settle disputes or help 
solve problems arising out of the matrix organizational set-up of each . 
center. Interestingly, the Apollo program managers at the centers each 
had had long working relationships with the center directors. They also 
had had long working relationships with the people who were the technical 
experts at the centers. These latter factors appear to be quite important 
in accounting for the success that the Apollo program organization enjoyed, 
using the matrix organization technique. 

One would suspect .where art agency ot a program office is involved in 
running many programs, the institutional agency-wide or program office-wide 
concerns would tend to dominate. Thus, size of program or project and its 
importance vis-a-vis the total organization are important variables to 
consider when decisions concerning the allocation of authority are made. 

It would still appear necessary to have a single authority point to bring 
about cooperation. But whether there should be equal allocation of 
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authority to both the functional and project dimensions, or whether 
grants of authority should vary with different sized projects and with 
different stages of the life cycle of the project is still pretty much 
an open question. Unfortunately, the uniqueness of Apollo does not 
provide much insight as to how these organizational problems can be 
solved in other organizations or at another time in NASA. 
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D. A COMPARISON OF APOLLO FIELD CENTER ORGANIZATIONS 

Each of the three operating centers of the Apollo program were 
organized differently. Huntsville was given the responsibility for 
building the booster assembly. Houston was given the responsibility 
for building the "manned” segments, the Spacecraft and the Lunar Module, 
for training the astronauts and for operating the mission. Kennedy was 
given launch responsibilities and associated final check-out and test for 
launch. Perhaps the first question might be; Why was the Apollo project 
broken out in dust that configuration? 

The scope of the Apollo program was vastly larger than any previous 
astronautical venture. Therefore, much that had to be designed and built 
was new. But there was the conscious attempt to keep and utilize what 
was already known and tested or at the very least what had an extremely 
high probability of working. Under these conditions it is reasonable to 
conclude that Huntsville, already part oi NASA and functioning as the ; 

booster experts for the Agency, would be given responsibility for design- 
ing and building what came to be known as the Satutn V . It is even more 
predictable when it is recognized that the director of the Huntsville 

Center was one of the technical experts primarily relied on when the nature i 

s 

of the apace effort and the needed booster capabilities were examined. y 

The decision to use Cape Kennedy, and build up a pad complex capable 

1 ! 

of launching the Apollo configuration was also quite understandable. f 

ft 

The selection of the director of that center also fits the general pattern, | 

•'A 

“ — “ I 

' l The site was already in use by NASA and skilled personnel ware ^ 

available. | 

if 




for he had a great deal of launch experience and was thoroughly lm\±l Jar 
with the requirements for a test and launch center to insure the success- 
ful firing of the Saturn V rocket. When the organization and management 
of Apollo at Cape Kennedy is compared to the other two centers, it appears 
to be quite unique. This is a function of the responsibilities it had 
and only insofar as necessary for the discussion of the organisation of 
the Apollo program will its character be commented on. Geographically, 

Cape Kennedy was aft obvious choice for the launching site of Apollo. 

Houston is somewhat different from the other two centers in that it 
was especially crested for Apollo. While the choice of the site is prob- 
lematical in terms of the analysis being presented, the personnel who 
manned the Center are not. There has been a great deal of controversy 
and dialogue concerning the choice of Houston as a center site, but not 
about the responsibilities assigned to the Center, nor about the individuals 
selected for key positions within the Center Organization. The men chosen 
to operate the Houston center were those in NASA who had the most experience 
planning and designing hardware for manned aircraft flight. Since before 
Apollo no one had manned spaceflight experience* this-seemed to be the 
logical group to be given this responsibility. Further, the group was 
given responsibility not only for the "manned 1 * spacecraft hardware but 
also for the men and their flight as well, thus, gitren the range of 
experience that existed, the Houston complex except for the site selec- 
tion, also appears to represent a conservative decision in terms of 
responsibilities for a portion of the Apollo effort. 


4his same group was also involved with the Mercury and Gemini progr* 
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Thus, to answer our first question, the original break-out of 

responsibilities to the three centers was understandable in the content 

of the past history of U. S. space efforts. It would have been possible 

to organize the effort in another way, with a lead center perhaps, or 

with only two centers — Huntsville and Cape Kennedy, for example* It is 

reasonable to argue that Cape Kennedy could have been expanded and housed 

1 

the Houston center. Why this was not done is not clear. But in any 
event, as a function of the high speed communication and transportation 
technology available in the 1960's, locating the center at Houston does 
not seem to have been a problem for the success of the program* In terms 
of the past history of space efforts, and in terms of manpower and exper- 
ience available, it certainly seems reasonable to assume that the three 
operating centers of Apollo were given their responsibilities because of 
the original inputs to the decision to "go to the moon" by the various 
groups who eventually rah the three centers. 

As with the 1961 Apollo decision, there are both favorable and 
unfavorable aspects associated with the use of three field centers and 
headquarters. All of the units were spatially separated and all, with 
the exception of headquarters, were concerned with tasks that could 
proceed in parallel and be integrated at a later time. 

The fact that Huntsville and Houston were separated and that the 
division of labor was so cleat impeded communication between the two 
centers. Thus, it was not unusual during most of the Apollo program, 

*One reason given for not combining Kennedy and Houston activities 
was the lack of s "local" resource base to support such a massive 
organization. 
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tor people at the middle and lower levels of the respective center 
organisations to have little or no idea about how the other center 
was organized and how work was proceeding. Interaction between the 
centers did. occur through the Management Council, through the program 
organization, and through the change control panels. But these inter- 
actions were quite specific to a problem or some narrow coordination 
difficulty, and thus the expertise relevant to tasks beyond a particular 
center's responsibility, by that center's own personnel, was not utilized. 
Also, because of the lack of a generalized set of interaction techniques, 
the work at Houston and Huntsville did not exactly fit and many integration 
problems rose to the surface at Kennedy. Because of little communication 
between Houston and Huntsville, for example, Kennedy had particularly 
difficult configuration and test problems to resolve. Also, because of 
the separation of Huntsville and Houston, the spirit of cooperation and 
high degree of integration of the total organization working on this 
monumental undertaking was thwarted. It is fair to say that some animus - 
existed between these two centers, and it was exacerbated by their separa- 
tion both functionally and spatially. 

The separation of the three centers and headquarters certainly con- 
tributed to all of the coordination problems which were continually trouble- 
some for the program. The separation also was related to a general tendency 
to projectize" tasks associated with Apollo. That is, at Headquarters, 

QMSF was spatially separated from the rest of NASA headquarters. At each 
of the centers * there was an effort to get the contractors to separate 
out from the rest o t their work, the portion concerned with Apollo, and 


to create an organization to run their piece of Apollo within, but 
clearly separate from the rest of their organizations. 

While It in true that this tendency to "projectize" parts of the 
Apollo program had unfortunate consequences there were also benefits 
to be derived from this procedure. The breakdown and isolation of 
separable pieces focused responsibility for the different parts ori 
highly visible units within industry and facilitated the monitoring 
of the contract. From the perspective of the contractors, it tended 
to enhance interaction between the center and the contractor. It also 
allowed more concerted effort to be focused on producing a reliable, 
high performance piece of hardware. This separation was also beneficial 
for the centers in that it gave a unity of task to the total center and 
tended to enhance relationships within each of the centers. This was 
particularly important because of the "built-in" conflict mechanism 
associated with the matrix organization that existed at each center. 

The coordination problems at Kennedy were certainly aggravated by 
the separation of task and separation in space of the other two centers. 
For the group at Cape Kennedy to do its job properly, there should have 
been constant Interaction between it and the other two centers. To design 
adequate configuration, test, and launch facilities, Kennedy should have 
had a view into the "innards of the bird" at Huntsville and have been 
apprised of ail of the design and subsequent changes associated with the 
Spacecraft and Lunar Module. This was not the case m the two field 
centers developed a somewhat insular perspective due to their separation 
of function and their different spatial settings! • 
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The organization of the Muntsvi Ho and Houston Centers were quite 
different. This was partly due to the insular perspective of each center, 
noted above, coupled with the tasks they had to perform, their past history, 
the existing state of the art, and to a degree the kinds of individuals 
involved in running the program and running the centers. One difference 
between the centers is captured by noting that Huntsville had a strong 
project organization and Houston a strottg program organization. At Huntsville, 
the stages were relatively clean pieces of the Saturn V complex and hence 
even though there was a program manager, his coordinative function was sim- 
pler compared to Houston. The project or stage managers were mostly from 
the R&DO side of the Huntsville house and were well aware of the expertise 
that existed in the labs of R&DO and the "performance" commitment of the 
laboratory directors. Also, the stage managers were mostly highly tech- 
nically qualified and as a consequence were in a position to decide issues 
involving a schedule-performance tradeoff. Each of the stages was such that 
they could be built relatively independently of each other, as was the case 
with the engines which were parts of the stages. Therefore, at Huntsville 
there was a series of projects, related biit quasi-independent, managed by 
strong project or stage managers. Except for the S-II stage, the major 
tasks involved enlarging already existing boosters and for the first time 
manufacturing them out of house, to insure the meeting of schedule check 
points, the project or stage managers had the major problem of relating 
to the strong technical in-house expertise that existed in the labs at 
Huntsville, and the newly developed expertise that existed at the contractors. 
The resultant "troica" of schedule, performance, and cost decisions made 
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by the stage manager wi th coat emphasized by the contractors and 
performance by the R&DO people resulted In a strong project orienta- 
tion. The program manager was a back-up for the stage managers, and 
since he had also been with the Huntsville group for a long period of 
time, he could help ameliorate problems that arose between the project 
manager and the labs over in-house or contractor issues. Further, the 
program manager had the confidence of the. Center Director who took a 
strong hand in the running of the Apollo program at the Center, and as 
a result could get the assistance of the Center Director in helping 
maintain program and project perspective. There is little doubt that 
Huntsville R&DO people had a great deal Of technical expertise, both in 
terms of design and planning and in terms of fabrication, and as a result 
tended to dominate the Center. Further, the past experience of the 
Huntsville people derived from the Arsenal Concept of doing the complete 
job with the same people, in-house. Thus, it is a great credit to the 
selection process that it allowed quite strong project managers to be 
chosen* who for the most part had the skills necessary to allow program 
arid project consider at ions to surface in such an environment. 

tJnlike Huntsville, Houston was characterized by a strong program 
organization. At Houston, there were not clearly separable pieces, except 
for the Spacecraft and the Lunar Module. In these two instances there 
were project managers similar to Huntsville but they were located in the 
Program Office, there were also functional directorates at Houston which 
had direct inputs into the Apollo program but in a manner far different 
from that which was obtained at Huntsville. Mission Control needed constant 
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interaction with the design and fabrication of the Spacecraft and Lunar 
Module, as did the astronaut directorate. The resulting man, communica- 
tions, and hardware interactions, superimposed over hardware being designed 
and fabricated at the frontier of the state of the art both by in-house and 
contractor groups, necessitated a strong overall coordinative device. As a 
consequence, the program organization at Houston was the focal point where 
decisions were made and trade-offs achieved among safety, performance, and 
cost by the program manager, and cost, performance and safety by the contrac- 
tors. At Houston, unlike Huntsville, the functional directorates did not 
dominate the organizations , basically because the technical experts had no 
base of experience in managing programs, the state of the art was to some 
degree unknown, and because of the man, communication, and hardware inputs 
all impacting and affecting the nature of the Spacecraft and Lunar Module 
conf iguration . 

For Huntsville the major management problems involved setting up 
procedures to allow the project managers to manage the stages and thereby 
allow project considerations to dominate. At Houston, the major problem 
was building a program organization which could manage the great diversity 
extant at Houston and which could meaningfully involve the technical 
functional directorates located at the Center. The degree of success the 
program orientation had at Houston, to a measurable degree, is a function 
of a strong program manager who had a long history of association With the 
center personnel, and who was skilled enough to maintain program emphasis 
while encouraging center functional and contractor support. At Huntsville, 
the organizational sUccesA of the Apollo effort is to a measurable degree 






a function strong project managers (stage managers) backed up by a 
technically and organizationally competent program manager and center 
management . 

The success at each of the centers, with somewhat different project 
or program organizations is strong evidence for the nature of the task, 
the personnel available, the experiential base, and the prevailing know- 
ledge or state of the art, all interacting to produce a viable form of 
organization and management. The form of the project or program organi- 
zation was variable and stabilized only after a series of trials and 
errors. Perhaps this is necessary with research and development work of 
large scale and technological complexity. If SO, it means that too much 
organizational and management planning is not appropriate for the develop*- 
ment of successful projects and programs. It might be hypothesized that 
there must be a trial and error management and organization process 
analogous to the preliminary design and analysis phase of the actual 
research and development process which takes into account the uniqueness 
of the organizational setting, the task, the personnel, and other relevant 
factors. 
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E. GENERAL ORGANIZATIONAL CONSIDERATIONS 

Among the large number of organisational innovations Introduced by 
NASA and the Apollo project, two stand out; the creative use of ambiguity 
and conflict, and the extensiveness and flexibility of the feedback net- 
works from lower to higher levels of the organization. 


1. Creative 


tuitv and Conflict. The issue here involves 


the apparent purposeful use of conflict as a mechanism to insure control 
by the top of the NASA Apollo organisation. The institutionalisation of 
conflict is accomplished by either, or both, of two related techniques; 
partitioning responsibility in such a manner that it tends to exceed the 
degree and scope of authority associated with the responsibility, and 
delegating overlapping responsibility and/or authority such that some 
ffissbigaity exists as to how problems which arise are to b© resolved » An. 


responsibility for building some stage of the rocket and making sure it 


authority If leas than his responsibility in his dealing® with rad 
personnel end contractors'. Thus, he is forced to rely on personalised . 
techniques to accomplish his task rather than exercise delegated authority- 
Where issues cannot be resolved, they are brought to the attention of high* 
level# in the organisation for resolution. Though highly simplified, this 


contractor 


make salient some 
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be quite functional for an organization in insuring some modicum of control 
in highly decentralized, technologically complex organizations. It also 
suggests that structured conflict can be utilized to more personalize rela- 
tionships in large organizations. Lastly, it suggests that this particular 
form of institutionalized control deals mainly with the productive aspect© 
of organizations. 

An example of institutional conflict in NASA is the creation of a 
variety of manager© (project, functional, and institutional), all with 
some overlapping responsibilities and authority, essentially related to 
maintenance activities. Here the institutional, functional, and project 
managers tend to compete for scarce resources, men and money, and where 
conflicts arise, they are either settled by personalized interaction or 


by being brought to the attention of those at higher levels of the organi- 
zation. the conflicts basically develop because there is no clear delinia 


tion of responsibility and authority in terms of maintenance activities and 
as a result a good deal of ambiguity exists. 

While the two methods of instituting conflict result in essentially 
the same things, control exercised by the top of the organization and more 
personalized relationship® at lower levels of the organization, they are 
different in one very important respect. One form of conflict Is oriented 
toward production activities and the other toward maintenance* It ia 
interesting to note that of the two* the one that worked least well in 
NASA was the one instituted to deal with maintenance activities* 


2. Extensive ~ sM Flexible feedback Ne twork s. A persistent issue, 
facing all organisations is whether hierarchical or horizontal relationship's 
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should predominate ami the consequences that flow from that decision. 

NASA has worked out a mechanism that potentially has the capacity to 
overcome this dilemma, the creation of change control panels which were 
ostensibly used as a configuring device. In general terms, one can think 
of an organization as comprising a series of relatively insulated levels 
and within these levels, a series of relatively insulated sub-units. As 
problems arise that cannot be solved by the sub-units, the formal mechanism 
of a single level change control panel is initiated. Discussion of the 
problem among sub-units* at a single level either leads to the resolution 
of the problem or brings it into clearer focus and makes more evident the 
scope of the problem. If the scope is too large to be handled at any one 
level, members of the sub-units, now representing the variety of interests 
at a particular level, help initiate a change control panel at the next 
highest level where the potential to resolve larger scope problems exists. 
The exercise is repeated and either resolved or a next higher level panel 
is convened. In essence, the process is an emergent one growing out of the 
nature of the problem and its scope. While each particular problem resolu- 
tion represents a substantive instance of the change control panel structure 
being utilized, the structure always remains as a viable problem solving 
mechanism, the numbers of levels involved varies from problem to problem, 
essentially determined by the scope of the problem, its importance, the 
amount of resources necessary to resolve it, the. difficulty associated 
with its resolution, end proximity to launch time. 

While this organisational Innovation has only been outlined (see 
Chapter XV for details ) » it appears to fee a wide ranging device to handle 




feedback from lower to higher levels of organizations in a truly creative 
way. The assumption is that roost occurrences are routine in organizations 
and can be handled at the sub-unit level . Where this is not so, the formal 
mechanism exists to actualize a decision-making apparatus that involves 
potentially all levels of an organization. This mechanism assumes that 
problem definition and resolution proceeds inductively from the smaller 
sub-units to higher and more far ranging levels of the organization, and 
that members of all necessary levels ere importantly involved in the final 
problem resolution. There axe some important issues that are related to 
this conception of the change control process as utilized by NASA and Apollo. 
For one, is the particular procedure only useful when you have a situation 
of geographically dispersed field centers and contractors and where you are 
dealing with quite complex and highly inter-related hardware assemblies? 

Here the issue is the generalizeability of the procedure. Another issue is 
whether this is mainly a feedback device for dealing with production activi- 
ties or can it be modified to deal with a wide spectrum of problems associated 
with organisations? Another issue is the degree to which levels and sub- 
units within a level of an organization can be decentralized and the suit- 
ability of this device. Yet another issue has to do with the nature of 
the organization that is most appropriate for this kind of procedure. Is 
it only useful for organizations dealing with advanced hardware construc- 
tion or can it be utilised for all ki- ids of organizations? There are 
certainly other issues related to using this kind of technique, but the 
important point is that here is a novel feedback mechanism used with success 
by NASA, that should be explored for its general • usefulness and application. 
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The Apollo management organisation also contains other elements 
worth noting as they potentially have relevance for any complex, large- 


scale undertakings, 


3. The creation and maintenance of a strong in-house technical 


and managerial base for the Apollo program functioned to provide NASA 


with the skills necessary to help design, manage* test, and successfully 


complete the hardware and software tasks. It can be hypothesized that to 


insure the successful completion of a large scale venture, an organization 


assigned such responsibility must have technical and managerial skills 


equal or surpassing those who assist the organization in the venture 


(see Chapter IV) . 


4. As part of its management responsibility, the Apollo program 


organization adopted procedures which resulted in detailed and extensive 


surveillance of contractor activities. The complexity of the undertaking , 


its importance, and MSA’s overall program reiponsibility , were major 


factors in this' development. Although there were difficulties related 


to contractor autonomy and as well, general coordination problems, this 
procedure appeared to be essential to the successful completion of. the 


program (see Chapter V) 


5. The "purposeful use of conflict" was Utilized to overcome the 


control among competing authorities, i.e.» insti- 


tutional position authority (field center head), technical authority 
(director of fi£ik>), and program authority. Conflicts occurred within 


centers, actoss centers, and involved headquarters and' the contractors. 


The use of this conflict was successful because' of' the strong commitment 


to the success of the program. 
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a) Conflict was resolved by Informal meetings, hardware 
reviews, change control boards, status -reviews, etc* 

b) Decisions which resolved the?, conflict were made known 
to the parties and rationales provided. Appeal proced- 
ures were available to the participants* 

It can be hypothesized that one way of resolving the authority 
and responsibility diltmaa in organizations, which is a function of 
positional authority versus technical skills, is the controlled use 
of conflict (see Chapter III) . 

6. Every effort was made to standardize the management and 
coordinative procedures in the Apollo program* Given the fact that, 
this was a research and development program, an effort was made to 
standardize all relatively routine maintenance actions, evaluative 
activities, and tepor ng procedures. The standardization represented 
an attempt to conserve resources for the "unknown” parts of the program. 
It can be hypothesized that research and development activity contain© 
both novel and traditional aspects and that the traditional aspects 
should be standardized to optimize organizational response to the novel. 

7. For the Apollo program, schedule was the foremost consideration 
and trade-offs were effected which dfe-emphasizbd coat and ©hphasized pet~ 
fonasnee and safety, while maintaining strict adherence to schedule. It 
can be hypothesized that while schedule, performance and cost parameters 
are 'all management constraints, emphasising any one of them" is probably 
beneficial for the completion of a program and has important implication© 
for the management of., the program, as well. 
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8. in the Apollo organization, throe general dimensions had to be 
coordinated; the technical or scientific, the overall internal organiza- 
tion, and the social# political, and economic environment. The Apollo 
program proceeded relatively smoothly when top NASA leadership consisted 
of three Individuals; one who looked outward, one who acted as an internal 
general manager, and one who looked after the technical and scientific 
considerations. When this tri-partite division of labor was disbanded in 
1965. the problems of NASA as an agency and in particular the Apollo program, 
were increased. It can be hypothesized that any technical organization, but 
particularly those organizations involved in R&D work, must constantly moni- 
tor all three dimensions and work out mechanisms to coordinate the various 
activities Associated with each dimension. 

9. The Apollo program utilized the technique of “projectizing" critical 
tasks or problems which arose in the course of the project. Closely allied 
to this procedure was the use of task forces. It can be hypothesized that 
the successful utilization of these temporary, si tuationally specific organi- 
zations was directly related to the degree they were perceived and utilized 
as temporary and high priority operating units. 

10. As the Apollo program reached conclusion, there was a prolifera- 
tion of control and reporting mechanisms resorted to by top management, 
to insure the coordination of the diverse parts of the program and to re- 
establish agency dominance over the program. For the most part these 
appended controls were indicative of the imbalance' between program and 
host organization. Bue to many different factors, Apollo dominated over 
agency concerns, and vhe continued survival of the agency at its existing 


size was thr£<ifceft€!d with thtf termination oi the program* Xt can be 
hypothesized that only when the total organization la created for a 
specific task, and therefore perceived as a temporary rather than an 
enduring organization, is it beneficial to allow program activities to 
become superordinate . 
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CHAPTER III 


A. MANAGERIAL ADVANTAGES OF NASA'S PROJECT MANAGEMENT SYSTEMS 


Our investigation of the NASA project approaches uncovered a number 
of important advantages associated with the management of complex tasks. 

This section discusses what we consider to be some of the most outstanding 
characteristics of the Apollo project management system. 

As we viewed the Apollo program, several basic variables became evident 

1ft explaining the rationale of why a project management approach was Utilised 

and why project management was probably mandatory. The tasks undertaken in 

placing a man on the moon were exceedingly large, complex, costly, and required 

the effective coordination of thousands of individuals, millions of pieces 

of hardware, and thousands of private contractors and universities. As one 

observer cogently noted: 

In terms of numbers of dollars or of men, NASA 
has not been our largest national undertaking, 
but in terms of complexity, rate of growth, and 
technological sophistication it has been unique.. 

Involved have been a government headquarters and 
widely dispersed set of laboratories and techno- 
logical facilities; some 20, GOO industrial con- 
tractors, sub- contractors, and suppliers; almost 
400,000 non-governmental workers; and faculty 
members and students at 200 universities, keep- 
ing all these parts— often working right at the 
edge of technological knowledge and capacity— 
finely tuned and in close harmony has been an 
organisational achievement of high order. 1 

Since the task was considered too large to be undertaken by an all 
"in-house” NASA effort, a NASA/ private contractor /university Consortium was 
established as the primary "team." NASA assumed the role of technological 


^Dael Wolfie, 


"The Administration of NASA," Science . November 15, 1968. 
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leader while the supporting private contractors and universities were 
delegated the responsibility to help design, fabricate, test, and deliver 
a significant portion of the program's necessary software and hardware* 

To assume the role of team leader, NASA relied on its strong in—house 
te chnical and managerial capabilities to initiate, direct, and monitor 
the work of contractors. As we have alluded to previously, without 
the high degree of in-house technical competence, NASA would not have been 
able to direct the development and manufacture of the necessary hardware 
undertaken internally, nor would it have been able to effectively monitor 
the tasks being undertaken by the thousands Of contractors and sub-contractors. 
The entire development of the Apollo hardware was truly a "team effort" with 
NASA and its contractors working jointly on the various projects. 

In addition to assuming the role of technical leader, NASA also had 
to assume the role of management leader in managing the cost, schedule, 
and performance objectives of the Apollo program. 

1. Problem Orientation 

The basic characteristic of project management is that a specific 

1 

problem requires solving. Often within Apollo problems were unique one- 
time undertakings where there was prior organizational experience. The 
problems to be solved in the Apollo program normally had three ancillary 
objectives— to solve the problem within stated performance objectives, 
cost objectives , and by a given schedule. Often these objectives determined 
how the problem or project would be managed, who would manage what sub- 
tasks* what trade-offs Could be made, and how various simultaneous tasks 

1 

See D. L. Wilemovi, "Managing Product Development Systems: A Project 
Management Approach." Business & Economic Dimensions' , May, 1970, pp. i.4-19 » 
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could be sequenced to "telescope" the task's development time. 

The "problem" in Apollo was to safely land a man on the moon. This 
was the starting point for all the other activities which had to precede 
the actual accomplishment of the objective. The major "problem" was then 
analyzed to determine what other problem must be completed before that major 
objective could be accomplished. This procedure, in effect, segregated the 
major problem into thousands Of distinct steps necessary to reach the 
ultimate goal of safely placing a man on the moon. 

2. Multidisciplinary Emphasis 

The nature and scope of complex problems frequently demand the inputs 
of several discipline-oriented specialists within and external to an organi- 
zation for problem resolution. The problems encountered in Apollo often 
involve more than one basic discipline— thus expertise from other areas Of 
expertise within the organization needed to be coordinated to effectively 
resolve problems* In essence, complex problems required the systematic 
integration of both technical and managerial expertise. For the most part 
the Apollo project organizations were designed to provide for the effective 
integration of the problem-solving capabilities of various discipline-oriented 
specialists, in Apollo the interdisciplinary efforts at problem-solving took 
two basic forms. The first case entailed discipline-oriented specialists On 
the immediate project team. If a problem developed these team members were 
expected to apply their expertise to the resolution of the problem. The 
second case occurred when problems arose where the necessary talent to 
resolve it were located An other parts of the NASA organization or external 
to it as was the case with supporting contractors . 
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3. Responsibility Identification 

Project management approaches are designed to employ a deductive approach 
in breaking a project down into manageable segments. More specifically* a 
problem is broken down on a "systems" or "subsystems" basis, in Apollo, for 
example* the hardware necessary to accomplish its objectives were identified 
the S-1C, 3-11, S-1VB , Command Module, Service Module, Lunar Module, Engines, 
and Ground Support Equipment, etc. Each of these were distinct projects 
because they possessed certain integrated characteristics. A manager was 
assigned as the principal manager (project manager) for each system with 
overall responsibility for cost, schedule, and performance objectives. 
Management responsibility Was further assigned to each of the project's 
primary Components or subsystems. For the S-1C vehicle, for example, sub- 
system managers reporting directly to the S-XC project manager were given 
responsibility for critical components. Subsystem managers, for example. 

Were assigned to S-lC's mechanical structures, the propulsion system, the 
electrical systems* the instrumentation flight control systems, the environ- 
mental control systems, and the necessary ground support equipment. Because 
of the complexity of the task and the interface relationships* an organiza- 
tional matrix was established to pin-point inter- and intr a— organizational 

. r ■ _ , r - t . 

relationships. The development of these matrix-oriented responsibility 
relationships, proved to be a significant innovation in managing the Apollo 
program. 

The ptoject/matrix organitati arrangement used in Apollo hot only 
pin-pointed. -the project manager and his subsystem managers bat also helped 
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delineate the technical supporting personnel found in NASA's various labora- 
tories; the resident managers at the contractor’s facilities, and contractor 
counterparts. These matrix relationships made clear who was responsible for 
what task and assisted in establishing a system of accountability throughout 

the NASA/Apollo drganiiation. 



4 . Systems Perspective 

Closely allied to the preceding discussion bn the ability of project 
organizations to identify key responsibility areas, is that a project approach 
assists in giving top management an opportunity to view the "project" as an 
"action system." From an organizational perspective this allows 
to survey the total performance of specific projects, project 
ships, and the relationships Of the projecte to the institutional and functional 
areas of the organization. On large projects where considerable resources of 
the organization are being expended, this becomes crttcial in terms of effec- 
tive resource control and the minimization of conflicts over these resources. 
Frequently, for example, conflicts arise over priorities and resources among 
the various tasks any organization undertakes. If top management can maintain 
an overview capability of all the projects, bjr developing effective information 
management systems, they will then have a potentially valuable management tool 
to assist in allocating resources On a more rational basis. 
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The development of project management methoda have ptoduced a number of 
innovations in the why organizations have traditiohaliy-functioired. Most 
organisations, for example, group their specialists under "ftinctiSnal" areas, 
such aa, research end development, engineering, manufacturing, etc. 
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The specialists in each function report to a manager who has primary 
responsibility for maintaining their expertise arid the qualify of work 
performed by these specialists* However, as the tasks undertaken by large 
organisations became more complex in size and scope, the ability to coordinate 
these diverse groups of specialists became more difficult as in Apollo. 


Moreover, because highly technical projects required quick-acting , multi- 
disciplined inputs, they tended to require intensive coordination across 
organizational iines rather than vertically. 

While there are many advantages inherent in the standard functionally- 
oriented organization Structure , there are numerous disadvantages which 
affect an organization's ability to manage large, multldlsciplined tasks. 
When an organization is organized primarily on a functional basis, the 
tasks of mobilizing diverse organizational resources among its various 


functional areas often becomes both cumbersome and difficult and raises 
such questions as follows : 

1. Who determines what resources are needed, when they are 
needed, and how they will be employed? 


2. Who has the authority and responsibility for mobilizing 
the needed resources across organizational lines? 

3. Who should have the authority to mobilize the needed 

"** ' resources? 


4. What organizational meehsniam.groups qi; manager 
serve as the primary coordinator for the' task? 

fk Mow .are priorities determined : thatarise. 

needs of mult idisclpilned tasks and the mseds Of the 
functional organization?' 

Such questions point ©ut the need of e management system which can operate 


within and -through ah 


's functional structure, ' The WASA project 


r 
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management system assisted is delimiting many of these problem— areas . In 
addition* functionally oriented organisation structures often become ’’power 
centers*’ within an organisation. The project management approach attempts 
to delimit these actual and potential power centers by focusing organizational 
strengths on tasks to be solved rather than on particular disciplines. 


6. Communication Flexibility 

In the project organization a network of communication channels evolve — 
both formal and informal. The Apollo project management approach appeared 
to offer two principal advantages in terns of organizational r munication. 
First, the project organization was established so that it would have a - 
minimum of hierarchical restraints in communicating with top management. . 
Moreover, Since the project organizations often had a short chain-of -“Command, 
the communication efficiency among the Apollo project team members and 
project managers Was enhanced. Directives from top management usually 
could be funheled directly to the project Organization. Such a communica- 
tion advantage offered speed, flexibility, minimal communications distortion©, 
and more rapid decision-making capabilities. 

In summary, the Apollo project management Organizations were designed 
to Operate both Vertically and horizontally within the larger HASA "host” 
organizations the Apollo project organizations'' were then an over-lay 
eat ion on the MSA functional organization whiekailowed the project 


L In the Apollo Program,; for 


"task for'cO_ teMBS** pr "tiger teams** 
notice to resolve the' problem.. 



developed. 
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B. ROLE OF CONFLICT IN APOLLO PROJECT MANAGEMENT 
I# Intro duction 

The objective of this section is to explore the role of conflict in 
Apollo project management, examine its determinants , and analyte both the 
positive and negative consequences of conflict. Conflict in the project 
environemnt IS defined as the behavior of an individual, a group, or an 
organization which impedes or restricts (at least temporarily) another party 
from attaining its desired project goals. Even though conflict may impede 
the attainment of project goals, the consequences may be beneficial to the 
project if it produces new informational inputs which enhances the decision- 
making process* Conflict becomes dysfunctional if it results in poor 

1 

decision making and a disintegration of the efforts of a project team. 

The significance of Marshall Space Flight Center's (MSFC) approach to 

project management is related to the complexity of the projects undertaken 

and the degree of coordination required to integrate NASA in-house expertise 

with the scores of supporting contractors. Early i«t the Apollo program a 

decision was made to utilize two parallel SuhOrganizatioae to support the 

Apollo projects, i.e». Research and Envelopment Operations (RABQ) and 

2 

Industrial Operations (10) * This decision msdi it possible to provide both 


This section is based on the paper, 
a paper presented at .the' Third A nnual Sam: 


meat Institute , Houston, Texas, October 1% 1971 


nfcly the names of these two' 
and OeVAtopaeat %©rat ions' is now Science 
Operations is nm called Program Itahtegametit and two 
been c rested -as noted In Chapter IV* 



specialized technical support and a managerial over-view for each project. 

While the project groups in 10 function on a programmatic basis, the 
R&DO organization operates on a "functional" basis and houses technical 
experts in virtually every engineering and scientific discipline relevant 
to space exploration. Personnel in the R&DO laboratories supported and 
assisted the various project groups in 10 in planning projects, in recommend- 
ing and implementing needed engineering changes, and in evaluating the 
technical and engineering capabilities of the supporting Industrial contractors 
Having much broader responsibilities than the R&DO support personnel 
the project managers in 10 were charged with the overall management of the 
business and technical dimensions of their projects, the project managers 
responsibilities thus encompassed the critical variables of project performance 
schedule, and coat. Usually reporting to each project manager were several 
subsystem managers, these subsystem managers were delegated responsibility 
for the cver-all management of a critical subsystem. 

f 


Apollo project managers were required to cross oottt m-nouse organize 
tinsel lines and transcend external Corporate structures to elicit needed 
Support for their projects# the necessity to coordinate diverse organizer 
units (R&DO, the contractors and SO) often fostered conflict situations in 
the Apollo project environment 

'Maimaeraesit/feehsai 


Conflict frequently developed bet 
tiqn and the R&DO organisation*^ the' 'two "in 
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1 

project team. Some of the conflicts had deep-seated historical roots 
while others resulted primarily from differences in professional viewpoints 
and motivations. Historically, some of the conflict between the project 
management groups and the ft&DO groups can be traced to the initial Implementa- 
tion of the project management System within MSFG. A number of the key 
people in R&DO, for example, felt that they should direct the efforts of the 
supporting Industrial Contractors and that the Implementation of a separate 
project management organization probably was not teally needed. As a 
consequence, varying degrees of mistrust and conflict have occurred between 
the project management organization and elements of the R&DO laboratories. 

The conflict which ensued, especially early in the program, often resulted 
in power struggles which delayed decision-making. Contributing to the conflict 
was a lack of "organisational clout" by the project management organization. 

One approach taken by HSFC's top administrators early in the program 
to bolster the strength of the project organization was to hire top talent 
from outside NASA to man key positions in the project organization. lit some 
instances this practice Involved hiring executives front private industry with 

proven track-records in managing complex tasks as well as military line 

2 

Officers with experience in missile development and management , 


Hhere arc a number of conflict situations which occurred between the | 

project management organization and the contractetrs which are not dlsettiised v 

here but which are fairly typical in "contractor m«nog4®er«t" Bi<:uations. . | 

Mnagreements* for example, arising, over "the scope. of a contracts," "th©_ 
value of a contract," and' ."intent of a contract" are father common causes' j 

of conflict in contract management situations* | 

^Thi© practice was even more prevalent at the Manned Spacecraft Center. | 
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Although the R&D0 group’s responsibility was to provide technical 

direction for the projects, ambiguity sometimes developed over what was 

actually entailed in the term ’’technical direction." in essence, K$BO 

personnel could advise but did not have the authority to initiate project 

engineering changes outside the scope of the contract. In some instances, 

especially early in the program, attempts were made by some R&O0 personnel 

to direct the contractors without first clearing their actions with the 

appropriate project management personnel. One project engineer in a 

contractor's Organisation perceived the existence of conflict between 

the il&DO groups and the project groups in this vein: 

The main conflict that occurs within NASA is between the 
technical side and the project side. They have conflicta 
over who the hell makes the decisions.... 

As the above eguote implies, conflict sometimes existed between project 

management and ft&DQ over who had the "right" to issue directives to contractors. 

In effect, the lack of coordination between NASA’s project groups and the 

MDO organisation would, on occasion, directly affect the operation of the 

1 

contractor’s efforts. 

In addition to the historical sources of conflict, conflict often was 
facilitated by the divergent motivations Of personnel in the project management 
organisations and in ft&Dd. Personnel in ft&bo, for example, often ate highly 
motivated to achieve high Quality and reliability ratings for the particular 
project or subsystem they support. Project specifications, for example, may 
call for a reliability factor of 'T. Personnel it* R&DO, however, may feel 

l Se« Chapter V for further insights or this problem area. 
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a reliability rating of "R + /\ |* Is better and that the necessary steps 

Should be taken to change specs and achieve a higher reliability level. 

A project manager , on the other hand may. feel that the project's specif ica- 

tions are adequate and that accepting a higher "R" rating is not worth the 

additional cost nor the impact on his schedule. One project manager explained 

hew he perceived the motivations of his R&DO project team members this way: 

A lot of the Individuals in R&DO give you a lot of static. 

They are and they should be purists. They want to do the 
best job they can and they argue with you long and loud. 

A project engineer within the R&DO labs agreed * in principal, with 

the project manager's comment and stated: 

You can have a guy (in R&DO) that has nothing but technical 
responsibility. If he is only told that the system has to 
work right and woe be unto him if anything ever happens to 
it, he can afford to be absolutely stiff in his demands.... 

As both statements suggest, the basic motivation of the Supporting R&DO 

personnel is to achieve the best possible technical solution to a problem. 

Unless a project manager is able to modify these motivations the success 

of his project may be endangered. Again, a project manager is motivated by 

performance but also by a more encompassing "set" of variables, such as, 

the successful completion of his total project on schedule within established 

budget parameters. 

b. Conflict Within the R&DO Laboratories 

The impression may have been given that the R&DO laboratories always 
presented a unified front in their dealings with the project management 
groups or with the prime industrial contractors. Often there was as much 
conflict within R&DO over the resolution of problems as between R&DO aid 



the project managers. Differences in viewpoints, professional orienta- 
tions, and laboratory philosophy often engendered conflict within and among 
the laboratories. In cases where two or more labs within R&DO were involved 
in the resolution of a particular problem, conflict, often would develop 
between the labs over which particular problem-solving approach to pursue. 
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Some of the conflicts which occurred within R&DO also were promoted 

by "jurisdictional” problems. A large number of multi-disciplinary problems 

occurred in Apollo requiring the input of several laboratories. When problems 

occurred which required a technical input from R&DO, conflict might develop over 

who should be primarily responsible for the total resolution of the problem— 

1 

who should perform the "lead" in the problem's resolution, 
c. R&DO/Contractor Conflict 

Conflict also occurred between R&DO and the supporting industrial 

r. 

contractors. One project manager for a large, supporting contractor, for 

example, described a basic determinant of conflict between his organization 

and R&DO over problem resolution this way: 

1 think R&DO is pretty successful at wanting to 
control the program. . .Everything that involves 
the configuration and technical aspects always 
has to be blessed by the labs. It's a headache 
but I can't say that it is bad — they're there 
to see that we do a technical job properly. So 
it becomes a thorn in your side primarily because 
there are so many R&DO personnel who look at each 


■^See the discussion on the concept of "lead" laboratories in Chapter IV. 

^See Chapter V for the broader dimensions of conflict between R&DO/ 
Contractor Conflicts. 


problem. You can always find a better way to 
build a mousetrap and many of the cases are just 
that. « . .We have , however, uncovered many problems 
this way — so it's also been beneficial. 

Conflict situations often developed over engineering changes which were 
perceived to produce only small marginal benefits in project performance. 

In addition, conflict situations appeared to be. fostered when a number of 
people were involved in the technical decision-making process. 

3. Some Problems Resulting From Conflict 

If conflicts cannot be effectively resolved, a number of detrimental 
consequences can occur. First, the inability of a project manager to effect- 
ively manage conflict may cause the project decision-making processes to be 
lengthy and cumbersome. In Apollo, for example, when conflicts could not be 
resolved between the project organizations and the R&BQ labs, each party had 
the option of appealing to higher management levels. Such a procedure if 
exercised excessively, would delay project decision-making processes. 

Second, if conflict situations can. not be adequately resolved it may 
lead to excessive documentation on the part of team, members to protect them- 
selves in case of "finger-pointing” which might result from project failure. 

Third, if project participants perceive that conflict situations are 
detrimental and distasteful they may take measures to avoid confrontations 
and meaningful dialogues with other project participants over issues that 
might place them in a conflict situation. A comment such as, "If they don't 
want us to help them why should we be^t our heads against the wall," is often 
indicative of an attitude toward the avoidance of conflict. Project team 
members need to feel that their ideas are being judiciously evaluated and that 


This practice is sometimes referred to as maintaining "Pearl Harbor Files." 



they have an opportunity to "win" on some of the key project decisions . 

If supporting project participants feel that they are not being heard and 
perceive that they are being repeatedly and unfairly over-ruled , they may 
simply "withdraw" from willing cooperative support. 

Fourth, excessive conflicts among project participants may cause 
"coalitions" to be formed among some of the diverse groups supporting a 
project in order that their particular viewpoints will receive the maximum 
impact while minimizing the inputs of other groups. Sucn behavior may lead 
to "compromise situations" in order to get views expressed and thus lead to 
a sub-optimization in problem-solving. A number of project engineers in R&DO, 
for. example, felt that the project management personnel and the contractor's 
personnel would often align themselves on key project issues and thus limit 
an open exchange of alternative problem-solving approaches. If real or 
petceived alignments occur among the principals of a project, they can make 
the participants spend their energies preparing for "battle" rather than, 
engendering a mutually beneficial exchange of information and ideas. 

4. Summary Hypotheses 

By their fluid, interdependent nature project groups often promote 
conflict situations within organizations. A number of hypotheses are suggested 
from our study and prior researches that warrant further attention by any 
organization utilizing a project management mode. Each proposition suggests 
conditions and/or situations which may either increase or decrease conflict 
ttithln the project management environment . 

Hypothesis 1 

The greater the diversity of disciplinary expertise among 
the participants of a project team the greater the potential 
for conflict to develop among the members of the team. 




- 39 - 


One of the key differentiating characteristics of Apollo was the high 
degree of technical expertise found within the contractors, the R&DO organiza- 
tion, and the project organization. Due to the level of this expertise a 
number of conflicting problem-solving approaches would often be suggested* 
Several managers in NASA and In the supporting Industrial contractors 
suggested that the utilization of this high degree of technical expertise 
often varied greatly from the project management systems practiced within 
the Department of Defense. The existence of high degrees of diverse 
perceptions on a project team (as in the NASA context) was often related 
to the high degrees of expertise. And the more varied the perceptions and 

expertise the more likely conflict will develo p among the project team 
1 

members . 

Hypothesis 2 

The weaker the project manager's authority, reward, and 
punishment power over organizational units supporting 
his project, the greater the potential for conflict to 
develop . 

It appears that the project manager’s weak degrees of authority, reward, 

and punishment power over supporting project participants, R&DO, facilitated an 

2 

environment conducive to conflict. If a project manager has a high degree 
of reward power, those who support him may devote their efforts to the rewards 
they perceive he can give them rather than supplying the project manager 
with frank appraisals of a given situation. In a similar vein, if a project 


J. G* March and H. A* Simon, Organizations , New Yorks John Wiley and Sons, 
Inc., pp. 121-1.31, (1938) . 

2 

For a detailed discussion of the organizational consequences of using 
rewards and punishments on project team members, see G. R. Getnmlll and !). L. 
WlJemon, ’’The Power Spectrum in Project Management/’ Sloan Management Review, 
Voi. 12, Fall 19 VO, pp. IMS. * 
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manager is capable of punishing those who support him, the support 

personnel may attempt to avoid the punishments they feel the project 

manager can administer by supplying him with the informational inputs 

1 

they believe he wants from them. If the Apollo project managers had 
possessed high degrees of reward and punishment power over the R&DO personnel, 
it is likely that the Informational exchange between the two groups would 
have been less effective* 

Hypothesis 3 

The less the specific objectives of a project (cost, 
schedule, and performance) are understood by project 
team members the more likely conflict will develop. 

The more effectively a project manager is able to explicitly communicate 

the specific objectives of his project to those who support his project, the 

more likely dysfunctional conflict situations can be avoided. If, for example, 

the objectives of a project are ambiguous, conflicts may develop since project 

participants may be operating on the basis of different perceptions of the 

project’s objectives and their own role in fulfilling them. In the early 

phases of a project’s life cycle where project specifications may, by 

necessity, be ill— defined, there is often a greater likelihood that conflicts 


will develop than when specifications are more explicitly defined (as in the 
raaturer life— cycle stages) and can thus be more specifically articulated to 
project team participants. 

Hypothesis 4 

The greater the ambiguity of roles among the 
participants of a project team the more likely 
t hat conflict will 'develop. 


^In contrast, we might expect to find a low degree of conflict among the 
participants of a project group where the project manager has a high degree 
of authority over participants. 
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When the roles of various project participants are ambiguous (which 


they may have to be at times) there is a greater opportunity for conflict 


to develop. Role ambiguity can cause frustrations among those supporting 


the project and raises the question of , who does what? When feasible, a 


key responsibility of any project manager is to clearly articulate the roles 


of the various project team participants. Top management also can play a 


key role in establishing clear definitions of the roles project participants 


perform — whether individuals or organizations. It should again be noted 


that ambiguity may develop over the goals of a project as well as over the 


means to achieve the goals. Most conflict in Apollo, however, occurred 


over the means to achieve project goals, 


The greater the agreement on superordinate 


'oais by 


ect team participants the lowei 


the potential conflict. 


In Apollo, the presence of the superordinate goal, "a manned lunar 


landing," appeared to be a mediating factor which lowered the potential 


for detrimental intra-group conflict. The pervasiveness of this goal was 


constantly actualized by the highly visible program objectives of performance 


and schedule. If several diverse organizational groups support a project and 


there is a high degree of identification by each group toward a common super- 


ordinate goal, these groups will tend to lower their own goal identification 


and increase their identification with the goals of other participating groups 


in order to achieve the over-all objectives of a project. In other words. 


various groups jointly supporting a project must often make identification 


trade-offs with their own goals in order to achieve superordinate goals, 
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Thus, the effectiveness of a superordinate goal in mediating conflict is 

1 

dependent upon the degree of identification with it. One also can posit 


that the higher the degree of identification with a superordinate goal the 
lower the potential for conflict over the means to achieve a goal since 
alternative problem-solving approaches can be. delineated more* effectively. 

In Apollo, not only was there the very dominant single goal of 
achieving a manned lunar landing, there also was a number of "situational 
crises" which developed that endangered the over-riding superordinate goal 
at various times during the program. If, for example, a serious problem 
emerged which could cause a potential crisis to develop, there would often 
be a concentrated focusing by all the involved parties (NASA and the contractors) 
in resolving the problem. When these "crisis situations" developed, the 
existence of a high degree of intra-group cohesion was evident. One project 
team member discussed how he felt about a serious structural vibration 
problem as follows; "On a 'show-stopper* we're all in the same bed together." 

Hypothesis 6 


The more the members of a functional area perceive 
that the Implementation of a project management 
system will adversely usurp their traditional 
organizational roles, the greater the potential 
for conflict . " 


If the functional units in an organization, such as R&DO, perceive 
that the implementation of project management methods will significantly 
affect their traditional roles and responsibilities, it is likely that 


Sheriff, "Superordinate Goals in the Reduction of Intergroup Conflict, 
American Journal of Sociology, No. 63, pp. 349-338. 
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conflict will develop between the functional units and the project organiza- 


tion. When a project management group usurps an important part of a 


functional area's traditional mission, it is likely that the functional 


units will resist the efforts of the project group to perform those functions 


in some way or another. One often finds this form of conflict, for example, 


occurring between the R&D departments and project management groups in the 


area of new product development in private industry. 


5 . Role of 


A key role of the project manager is to optimize the beneficial aspects 
1 

of conflict. This may mean lowering the intensity of a conflict situation 


while in other cases it may involve inducing conflict among the project parti- 


cipants. Conflict may be induced by promoting the flow of diverse informa- 


tional inputs, by providing a facilitative environment for conflict, and by 


employing the emerging organizational development (O.D.) techniques. Creating 


a competitive atmosphere also is an important means of facilitating conflict, 


When conflict situations arose in Apollo the project managers most 


often attempted to resolve the conflict at the project level rather than 


resorting to arbitration at higher NASA management levels. All of the project 


groups we studied had frequent meetings which dressed their task-oriented 


conflicts. These meetings tended to be straight forward and allowed the 


involved parties to "lay their cards on the table". By employing such 


direct confrontation methods the project managers frequently were able to 


dispou- of problem situations before they became detrimental to the overall 


D. I. C lei and , "The Deliberate Conflict," Business Horizons, Vol. XX, 
No. I, pp, 78-80, (1968). 











1 

project. 

In terms of personal attributes helpful In resolving conflict, the 
project manager's technical and managerial expertise is critical. Not only 
can expertise assist project managers in gaining respect but It also can 
help them in the critical role of information gathering. The ability to 
collect, analyze, and disseminate information skillfully is mandatory in 
resolving task-oriented conflicts. 

In addition to possessing adequate technical and managerial competence, 
the effective project manager must also provide an environment for conflict 
to occur. In this vein he must view conflict not as a problem to be on 

2 

guard against and to avoid but rather as a source of ideas and information. 

For the most part, the conflict which occurred in the management of Apollo 

projects appeared to be task-oriented rather than based on interpersonal 

problems among project team members. In terms of the general effects of 

each form of conflict, Evan suggests that conflict based on interpersonal 

dislikes tends to be negatively associated with performance while task- 

oriented conflict tends to be positively associated with project team 
3 

performance. 


For an informative account of various approaches which can be used in 
resolving conflict by managers performing integrative roles, such as, project 
managers, see P. R. Lawrence and J. W. Lorsch, "New Management Job: The Integrator 
Harvard Business Review , November-December 1967 , pp. 142-152. 

2 

N. R. Maier and L. R. Hoffman, "Acceptance and Quality of Solutions as 
Related to Leader's Attitudes Toward Disagreement in Group Problem Solving," 
Journal of Applied Behavioral Science , pp. 373-386, (1965). Also E. P„ 

Hollander and J. W. Julian, "Contemporary Trends in the Analysis of Leader- 
ship Processes," Psychological Bulletin , pp* 387-397!, (1969). 

3 

W. M. Evan, "Conflict and Performance in R&D Organisations , " Industria l 
Management Review , Vol . 7, pp. 37-45, (1965) . 
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In conclusion) conflict is a fundamental characteristic of Apollo 
project management. The value of the conflict produced depends upon the 

4 

i effectiveness of the project manager in promoting beneficial conflict while 

7 concomitantly minimizing its dysfunctional aspects. A good project manager 

- v needs a '‘sixth sense" to indicate when conflict Is desirable, what kind of 

_ « conflict will be useful, and how much conflict is optimal for a given 

situation. In the final analysis he has the sole responsibility for his 

? ; 

project and how conflict will Impact the success or failure of his project. 



C. INTERPERSONAL DIMENSIONS IN PROJECT MANAGEMENT 


The objective of this section, is to investigate some of the inter- 
personal relationships existing within the Apollo project groups. More 
specifically, this section discusses how project managers Influence the 
technical specialists in the NASA organization over whom they have no direct 

1 

authority, but on whom they are dependent for Information and project support. 

In other words, what '’influence strategies" can a project manager use to 

accomplish the cost, schedule, and performance objectives of his project? 

In discussing the lack of authority over support personnel, one Apollo 

project manager noted the following: 

I think it makes it more difficult to get the job 
done when you have to rely on support people over 
whom you have no real authority. 

To identify how P.M.'s get support for the projects without formal 

authority we examined some of the primary influence techniques employed by 

2 

Apollo project managers. These influence techniques are most apparent and 
most easily understood when we view the project manager's relationship with 
those in the research and development laboratories and those within the 
various functional areas of NASA. 

We found that expert power , reward and punishment power , and referent 
power are the primary influence techniques employed by project managers. 

Expert power refers to the ability of the project manager to get his interfaces 
to do what he wants them to do because they attribute greater knowledge to him 


Portions of this section are adapted from G. R. Gemmill and D. L. Wilemon, 
op. clt . , pp. 15-25. Also see: G. R. Gemmill and D. L. Wilemon, "The Power 
Spectrum in Project Management," Working Paper No. 26, Syracuse/NASA Program, 

Feb. 1970, and D. L. Wilemon and G. R, Gemmill, "Interpersonal Power in Project 
Management," Journal of Management Studies , October, 1970, pp. 315-328. 

2 

See also, J. P. Cicero and D. L. Wilemon, "Project Authority — A Multidimension. 
View," IEEE Transactions on Engineering Management , Vol, 17, May, 1970, pp. 52-57. 
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or believe he is more "qualified" to evaluate the consequences of certain 
project actions than they are. Expert power can come from a project manager's 
managerial expertise or from his technical competence or both. In the area 
of managerial expertise the project manager may have abilities associated 
with the management of the project which enables him to build an lnfiuenc 
base over others. For example , the project manager is in a critical position 
that can allow him to have a systemic view of the total activities of the 
project. He knows what inputs and/or changes will affect the business side 
of the project. His management abilities are frequently demonstrated by 
his grasp of the complicated cost, schedule, and information systems attached 
to the project organization as well as his human relations skills. 

In some cases it appeared that it was difficult for the project manager 
to exert Influence based on technical expertise alone. However, this may be 
overcome if the project manager can view the project from a mixed technical/ 
managerial perspective. It may also be overcome by his demonstrated abilities 
and track-record in making sound project decisions. 

The ability to reward and punish directly or indirectly is another means 
by which project managers build an influence base. Although it appears that 
the project managers within the Apollo program cannot use reward power as 
freely as their counterparts in industry, in matters such as promotions and 
salary increases, they can reward project participants by: 

1. Giving recognition— both formally and informally. 

2. Providing organizational visibility. 

3. Assigning stimulating work assignments. 

4. Delegating responsibility. 
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Project managers can "punish" those who do not perform adequately by; 

Isolating them from the primary action of the project. 

2. Giving negative comments to the individual’s superior. 

3. By formal means, i.e. , documenting the individual's lack 
of compliance. 

4. Exposing mistakes of their interfaces to peer groups. 

Referent power was another important source of interpersonal influence. 

It is based on the degree to which the project manager's interfaces 1) identify 

with and are committed to the objectives of the project; 2) identiiy with the 

organizational position of the project manager; and 3) identify and value 

their relationship with the project manager as an individual and as a manager . 

One project manager explained the alue of referent power this way: 

I think I have the confidence of my support people. I'm 
able to call them and get a very quick response without 
any question. I think it's mutual confidence . . . that I'm 
able to get them to respond. I can pick up the phone and 
call any fellow in the support group and tell them we've 
got a problem at the Cape and you've got to catch a plane. 

He doesn't work for me, he doesn't owe me anything but 
he 'll do it ... . 

It appeared that a project manager possesses a good basis for Influenc- 
ing his support people if they could identify with him, or could find a 
common basis for respecting him. As one manager stated, "There's a philosophy 
here that you aren't a good project manager unless you've come up through the 
bowels of engineering... Another project manager agreed with his observation 
and put it this way: 

I guess I'm sort of lucky in that I came up with the 
support people so they don’t resent me. I have no 
trouble in getting along with them. ...It's been 
indicated that other managers who haven't come up 
through the ranks might have had more difficulty 
than I've had... 
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As Indicated, friendship ties appeared to be an important source of 
Influence for project managers. Those project managers who had the 
opportunity and time to develop relationships with those who supported 
them appeared to be better able to exercise referent power. To illustrate 
the Importance of referent power another project manager when asked how he 
knew who to ask for advice when he needed support replied s ''Strictly 
personal friends that I've cultivated over the years... and they may 
anywhere within NASA. ’' 

What is the best "influence mix" then for a project manager to employ? 


1 . 


If a project manager has too much technical expertise, it may 
thwart the contributions of his supporting team members If he 
over uses it. Full commitment by the team members may be 
weakened because it destroys their intrinsic motivations in 
problem-solving if the project manager attempts to dominate 
in all problem-solving situations. 


2. If he has too little technical expertise it slows down the 
decision-making process of the project. The project manager 
would frequently need to check on the advice he receives from 
his support people. In the process, he might lose control 
over his project. 


3. If the project manager has too much referent power his support 
personnel may not want to tell him he's wrong since they may 
fear it would damage their relationship with him. 


4 . 


If the project manager has too much reward power, it may weaken 
the strengths inherent in NASA's skill centers. Good support 
people may want to gravitate to project work rather than build 
expertise in a functional work area. It may cause an unbalanced 
reward situation with the rest of the organization. Support 
personnel may be afraid to indulge in independent problem-solving 
if the project manager has too much reward and punishment power. 


We conclude that the most effective style for project managers appears 
to be one based on expert and referent power rather than one based on the 
project manager's reward and punishment power or the use of his limited 
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degrees of authority. The expert /referent style seems best to promote 
independent, professionally oriented problem-solving. It is a model where 
the participants respond to "colleague authority" rather than formal authority. 
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D. SPECIAL PROBLEMS FACED BY PROJECT MANAGERS 

The high degree of intraorganizat ional interfacing and coordination 

rl required in project management and the complexity of the technology being 

dealt with produced a number of difficult problems for project managers . 

In this section we shall examine four specific problem areas which affect 

the role of the project manager. Wiese four areas include: 1) managing 

human interrelationships in the project organization; 2) maintaining a 

balance between technical and managerial project functions; 3) coping with 

various types of risk in the project environment; and 4) surviving 

1 

institutional restraints and rigidities. 

1. Managing Human Relationships 

The Apollo project managers and his immediate team members required 
the support and services of diverse professionals within and external to 
the project organization. At MSFC, for example, project management personnel 
required the support of scientific and engineering specialists within the 
R&DO laboratories. As previously noted, these professionals may have 
entirely different motivations which often conflict with the objectives 
the project management group is attempting to achieve. For project personnel 
to effectively cope with these diverse motivations it often requires effective 
human relations skills — -especially empathy. One project manager illustrated 
this point as follows: 

You have to understand who you are dealing with. 

An engineer in the laboratory may feel that he 
should settle for nothing less than zero leakage 
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This section is largely adopted from: D. L. Wilemon 
and J. F. Cicero, 'The Project Managers Anomalies and Ambiguities," 
Academy of Management Journa l, September, 1970. pp. 269-282. 


t^l‘ ... , * * . -1 . ' . v . . * ... * • - ‘ . •" 




72 


on a certain seal. He has a certain background, 
a certain psychological makeup that you have to 
understand, appreciate, and not violate. You 
can't tell a guy like that, go to hell, that he 
doesn't understand the problem. The guy can be 
a. Ph.D. and can darn well know exactly what he's 
talking about. So you've got to find within 
your own means the mechanisms for communicating 
with him. ..and then again you've got to realize 
that he's communicating with us. 


It appeared to us that the effective project manager is one who respects 


the motivations and viewpoints of his interfaces but is also able to get 


them to do what he wants them to do in terms of providing support, 


2. Balancing T echnical/Managerial Project Functions 


In managing his project, the project manager must maintain a balance 


between the technical and managerial requirements- of his task. When the 


project manager is directly confronted with a technical problem which may 


disrupt the designated objectives of his project, usually the project 


manager must make both a technical decision and a managerial decision 


before the problem can be resolved. For example, if research and develop- 


ment personnel inform the project manager that a critical component of the 


launch vehicle has only an "X" reliability factor, the project manager must 


weigh the technical decision of whether or not to accept the recommended 


reliability quotient against the overall management considerations of budget 


and schedule. Of course, when a problem occurs that has a high risk quotient , 


in terms of safety for example, the technical decision would outweigh the 


importance of the "management decision." As previously alluded to, a 


potential problem for the project manager lies in the possibility of over- 


stressing either the technical or the management dimensions of his project 
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The resolution of this problem appears to be in the project manager's 


understanding of his technical function and how he uses the project team 


to achieve performance requirements. While the management considerations 


as evidenced by the MSFC/Apollo model, are clearly the responsibility of 


the project manager, he also has final responsibility for the technical 


performance of his project. He may either become deeply involved in the 


engineering problems or he may leave many of the details to other project 


team experts and maintain a more distant position. 


Through analysis of interview data, the most successful strategy 


appears to be to display an understanding of and acute interest in the 


technical aspects of the problem while usually leaving its more detailed 


resolution to other technical specialists on the project team. A project 


team member emphasized this point as follows: 


All organizations suffer from having a man too 
interested in understanding everything* If that's 
the project manager's interest, 1 feel that he's 
misplaced. He can do a job, but it shouldn't be 
in management. He should be in a technical job... 
You sometimes can't reward a technical man... you 
put him in a management box and he makes things 
miserable. He's miserable and the people under 
him are miserable. 


Again, the implication is that to maintain the technical balance, the 


project manager should be concerned with the technical details and yet 


remain somewhat apart from the more routine details. 


While it is generally desirable for the project manager to leave 


many of the technical details to other team members, there are at least 


two mitigating conditions: 1) the perceived technical competence of the 


project manager; and 2) his ability to effectively use his project teg 






An important determinant in maintaining the technical balance is the 
project manager's technical competence as perceived by those who support 
his project. The project manager coming up through the NASA organizational 


ranks often appeared to have more respect from support personnel than those 
coming from an unrelated field or coming from a position outside NASA. Thus, 
a project manager's perceived technical competence often appeared to be based 
on both his prior NASA experience and his abilities as a project manager. 

As suggested, the project manager draws upon diverse organizational 
resources and his ability to effectively use the experts on his project 
team is critical for successful project performance. The effective manage- 
ment of a project team was described by one Apollo project manager as follows: 

A good project manager has to surround himself with 
experts. He doesn't need to be an expert engineer, 
an expert in finance, an expert in contracting, etc. 

He does, however, need a working knowledge of these 
things. For example, when an engineer starts talking 
to him about longitudinal oscillations, be has to know 
what the man is talking about. The prime thing that 
a project manager needs is the ability to listen and 
comprehend what his people are telling him. 

A fundamental quality of many Apollo project managers is their ability to 

seek information from several diverse sources, evaluate that information, 

and make decisions based on all the alternatives. In terms of a project 

manager's ability to evaluate information, one manager stated: "...to me. 


this is what makes a real project manager." 

3. Coping With Risk in the Froject Environment 

There are at least two categories of risk that seem especially relevant 
to project managers: l)project risk; and 2) professional risk. The first 
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form of risk, project risk, involves failure to »Jo an adequate management 
job which may result in project failure either in terms of performance or 
in terms of critical budget or schedule objectives. Professional risk, on 
the other hand, centers around the possibility of professional obsolescence 
as the result of long-term tenure on a project which could result in the 
project manager losing his technical competence. 

Project risk may be identified with the- project manager’s final 
responsibility for meeting and maintaining the performance, schedule, and 
budgetary objectives of the project. His success and the recognition of 
his ability as a manager, in part, depends upon his achievements in these 
areas. In effect, the project manager is the local person in a highly 
visible management responsibility system. For example, in the Apollo 
program, the project managers in charge of launch vehicles and engines 
roust frequently coordinate their operat ion:, with interfacing projects. 

In this sense, the project manager not only has responsibility tor his own 
project, but shares in a real sense the responsib. lity for the otlu r project 
managers ' hardware „ 

Two rather different perceptions were found to exist among the Apollo 
project managers in terms of project risk. The disparity in conceptualizing 
project risk may be illustrated by the following two quotations: 

* If my hardware didn’t work and it failed In lift-off, 
it would be a catastrophic occurrence. I would completely 
expect to be replaced. Put it that way. 

If you don’t want to accept the responsibility you don’t 
have to, you just buck it up to the next, manager and if 
he doesn't want to make the decision, he car. go to the 
program manager. 


la Llie i LihL ItiMtaiHH't the project manager perceives his responsibility 
as final and complete with the risk of project failure resting entirely 
on his shoulders. In the second case, the project manager Is left with 
an option of whether or not to accept complete responsibility In critical 
areas. The first case is relatively unambiguous, however p the second 
leaves assumption of project risk up to the individual manager. Further 
research may provide a workable hypotheses for understanding under the 
conditions that determine the amount of risk a particular project manager 
is willing to assume. The purpose here is to point out that project managers 
perceive risk differently. 

Apart from project risk, the project manager may also be confronted 
with a form of risk in terms of professional obsolescence. Advancement of 
the state of the art may bypass the project manager, for example, if he is 
unable to keep up with the rapidly changing practices in his engineering 
field. This is especially relevant in a rapidly changing program like 
Apollo where some of the major hardware projects have life cycles of eight 
to ten years. One project manager who had been in his position a number 
of years stated the implications of professional risk in the following 
manner: "I’m an obsolete engineer, I’m an untrained manager, and I’m too 

old to go back to school." 

4. Surviving Institutional Restraints 

Although project management is often defined in tenfia of its flexability, 
the antithesis of the traditional bureaucratic, model of organization, many 
Apollo team members indicated that certain institutional parameters developed 


over time which diminished the effectiveness of the project management 
concept. It was, for example, also suggested by some of the managers that 
the project management organization was not immune to 1 Parkinson s Law. 

As projects mature over their life cycles, various management systems and 
reporting mechanisms become attached to the project organization wh*ch 
produce rigidities and encumber ances . For example, over the life of Apollo, 
various "staff offices" at the field center levels and at Headquarters 
placed rather stringent demands on the project organisation in terms of data 
reporting systems, audits, and various types of project control requests. 

Many of these systems were not considered necessary by the project groups. 

One project manager explained how over a period of time, a project loses 
its flexibility this way: 

First you start out with a small organization and call 
it NASA. As you expand that organization you have more 
and more staff people at Headquarters and you have, more 
people thinking up reasons why there’s a need for a 
report. So, pretty soon you get hit with directives, 
some from Headquarters, some from every level. Many of 
these directives require comprehensive reporting; we’ve 
got a lot of people who think it would be real nice to 
have this report or that report, etc.... 

In order for the project managers to cope with increasing amounts of paper- 
work while maintaining peak efficiency in the management of their projects, 
they had to leant how to cope with the systems and data reporting require- 
ments placed on them. 

Aside from documenting the system, another variable which appeared 
to be a restraint on some of the project managers was the Civil Service 
rules, regulations, and requirements. Because of their rigid! tie®, these 
requirements frequently became problems for the project manager in selecting 


and molding a viable project team. For example, a project manager was not 
always able to choose his own men for his project no matter how qualified 
or how necessary they might be in terms of a particular task requirement. 


The man must first be "freed" from his present organizational position. 

One project manager alluded to the problem in this way: 

Nobody gets assigned to a job around here. You have to 
get permission from the people you work for. If it's 
just a lateral transfer, and say I really need a good 
strong project engineer, even If the center is in trouble 
and a man is around who isn't doing very much, if the 
person who is super vising his area feels strong about him 
and won't let him go, then you almost can't get him no 
matter how badly you need him... and that's kind of bad. 

The problem of assigning manpower to build the most effective project team 

also appears in the reverse situation. If a team member's performance is 

below an acceptable level, the project manager may also have problems in 

"spinning-off "unneeded personnel. One project manager concerned about the 

effectiveness of some members of his team made this comment: 

I've got three people I could do completely without. 

But, if I asked for their release from this project, 

I would most likely have to give up my three best man, 
so, I just sit here and don't say anything. 

The examples here only briefly touch the problems the Apollo project manager 

faces in surviving the system. If the project manager is evaluated in terms 

of how he meets his task responsibilities, any mechanism constraining optimum 

efficiency and flexibility is, in a real sense, a threat to the manager's 

capability of surviving the total project system. 
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Summary Hypotheses on Special Problems Faced by Proje ct 
There are a number of summary hypotheses which can be derived from the 
preceding discussion which warrant further observation, discussion , and analysis* 
We believe each hypothesis is significant in helping understand some of the 
more important behavioral problems faced by project management personnel. 


a. M anaging Human Relationships 

1. The degree to which engineering and scientific personnel 
associated with project teams are motivated to contribute 
to the objectives of the project varies with the project 
manager's ability to satisfy their professional goals 
within the context of the objectives of the project. 

2. The greater the necessity of utilizing scientific and 
specialized engineering personnel in project problem- 
solving, the less effective the bureaucratic form of 
organization becomes and the more likely the tenents 
of bureaucracy will be violated. 

3. The internal rewards in terms of motivation and ego- 
involvement for those who support the project manager 
are related in a positive sense to the project manager’s 
ability to encourage autonomous problem-solving, when 
feasible, for them. 

4. The greater the diversity of problem-solving situations 
available to project support personnel, the higher their 
motivation levels. 

b. Balancing Technical and Managerial Project Functions 

1. The greater the project manager's technical expertise, the 
more likely he will overly involve himself in the technical 
details of his project. 

2. The greater the project manager's difficulty in delegating 
technical task responsibilities, the more likely it is that 
he will over involve himself in the technical details of his 
project (depending upon his expertise to do so). 

3. The greater the project manager's interest in' the technical 
details of his project, the more likely he will defend his 
role as a technical specialist. 















c . Coping WJ.th Risk In the Project Environment 

1. The project manager ' » anxiety over project risk varies in 
relation to his willingness to accept "final" responsibility 
for the success of his project. 

2. The greater the length of stay in the project manager, the 
greater the tendency for project managers to remain in admin- 
istrative or managerial positions during their careers since 
technical avenues for career advancement will be limited. 


3. The degree of anxiety over professional obsolescence varies 
with the length of time the project manager spends in project 
management positions. 

d. Surviving Institutional Restraints 


1. The autonomy of a project manager decreases over the life of 
his project as institutional management and program 'management 
increases their desire for centralized project control. 


2. The higher the degree of bureaucratization in terms of report- 
ing systems, rules, and regulations, the more highly developed 
the informal communication channels of the project manager 
become and the more cumbersome the decision-making process. 



E. SUMMARY REMARKS ON APOLLO PROJECT 
management METHODS 

X. NASA’s top management might have been more adept when establishing 
program management at the field center level. We feel that it took 
too long with the result of too much conflict for project management 
to be established at the major field center level. 

2. Functional specialization, while facilitating in-house expertise, 
has promoted many organizational coordination problems within NASA. 

A parochial viewpoint by the labs at MSFC, for example, often hindered 
efficient intra-organizational coordination. In the future, more 
emphasis should be placed on disseminating a total agency viewpoint. 

3. Those who manage and select project managers and subsystem managers 
should place more effort on selecting those with proven depth in both 
technical and managerial experience# 

4. NASA should establish a formal system for training project managers. We 
suage *• perhaps the establishment of the position of "assistant project 
manager" would be helpful in training future project managers. 

5. Headquarters should continually monitor its informational requirements 
which it requires from the field centers, the project organization, 
and the contractors. As projects mature there is a feeling that too 
much information is required of the project manager which probably has 
limited value to the recipient. 

6. More training should be available to project managers in terms of inter- 
personal skills and Organizational Development (O.D.) techniques. Such 
training could facilitate their job of managing people and coordinating 


their projects. 
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7. A personnel system should be established which really allows for the 
flexible rotation of the younger subsystem managers and project, 
engineers in and out of both management and technical positions. 

Such a system would greatly facilitate the training of the younger 
personnel and would help reduce the problem of technical obsolescence 
while increasing the appreciation and understanding of the "management" 
viewpoint . 

8. NASA should not stifle in-house and Inter-center rivalry. It is 

recommended that NASA assess the viability of establishing "Venture Teams" 

to promote innovative ideas as currently employed by many industrial 
1 

corporations. 

9. NASA top management should examine whether the management structure 
at both field centers is excessive. For example, can PM and PD at 
MSFC be coordinated more effectively? 

10. A concentrated effort should be made for the infusion and cross- 
fertilization of engineering and scientific personnel between NASA and 
the universities. Such a program could facilitate the infusion of fresh 
Ideas and technologies to both NASA and the universities and potentially 
eliminate some of the problems fostered by t^e personnel policies forced 
on NASA. 

11. A system should be investigated which provides a faster, more effective 
turnover of personnel in key project management positions while still 
allowing for the important variable of continuity — especially for 
projects that are of long-term duration. 


D. I.. Wilemon* "Program Innovation in a Complex Program," Syracuse/NASA 
Program, Working Paper 6223-WP-9 , July, 1971. 
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CHAPTER IV 


A* THE SIGNIFICANCE OF IN-HOUSE TECHNICAL COMPETENCE 

The Apo.lla program was eminently successful by any reasonable 
standards* One therefore looks for the factors that assured the achieve- 
went of the goals in the time specified and with the money available. It 
is our contention that the maintenance of a strong in-house engineering 
capability was one major enabling factor In NASA's success in the Apollo 
program. It is difficult to imagine the achievement of the goals without 
it. Any other government agency that manages programs in which actions 
necessarily depend on professional decisions should consider emulating 
NASA in this respect. Whether the professional field is related to the 
physical Sciences (as in energy utilization) or the social sciences (as 
in public welfare) , the parent agency must maintain its own professionally 
trained staff. This in-house capability cannot be rented. While there is 
a place for consultants from universities and other institutions, these can 
only supplement and cannot replace the agency’s own competence. 

Of course the size, technical complexity, and boldness of the Apollo 
program were all staggering. While these forced NASA to adopt management 
practices that were in many respects new, the lessons of Apollo management 
should not be dismissed as unique and inapplicable elsewhere. One very 
significant lesson is found in the skillful blending of outside contract- 
ing with in-house expertise. The effective management of the program, 
including the management of the in— house talent, assured the successes 
achieved . 














The utilisation of Che private sector through prime and sub-cun tracta 


to accomplish the Apollo program is dealt with separately in Chapter V. It 


has been suggested that NASA could have contracted out either more or less 


of the responsibility, in the extreme making this cither entirely an in- 


house effort or, on the other hand, entirely a contractor effort with little 


NASA input or supervision. It was more than a political or social expedient 


to have private industry in various parts of the country employ the bulk of 


the manpower particularly in the final design and the fabrication phases of 


the program. It allowed NASA to utilize the technical competence of Indus tty 


without actually removing large numbers of scientists and engineers from the 


private sector, and it provided access to large manufacturing facilities with- 


out direct government ownership of and responsibility for the plants. For 


political and economic reasons, NASA could not have put on government service 


payrolls the number of people eventually involved in the whole Apollo program. 


Why then would NASA not have been wise to move towards the position of the 


Department of Defense, for instance, in giving to the contractor much more 


responsibility? 


The technical complexity , the use of astronauts, and the involvement 


of national prestige in the manned space programs plus a growing in-house 


competence in which there was justified pride probably saved NASA from 


what, in our opinion, would have been a grave error: the assignment of 


too much unsupervised responsibility to contractors. Intensive super- 


vision, though desirable, was not uniformly NASA’s practice even within 


the Apollo program. There were instances of serious difficulties arising 


from the practice of some administrators at certain times to trust the 
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contractor in reliability ami quality assurance as wciJ a a in design judg- 
ments. In this, MSC was more guilty than MSFC. 

In general there was no cut-off point for the respunoJ bilit y of NASA’s 
technical experts. For some individual pieces of hardware and some soft- 
ware, NASA's laboratories and research and development offices coup Jed with 
its limited manufacturing capability performed the whole task from concept, 


through design, to manufacture and test. But this was unusual . In most 
instances, the original concept and at least some preliminary design were. 
NASA's. This meant that people employed directly by NASA knew as well as 
anyone the objectives, the requirements, and the difficulties in the system 
or sub-system. When a contract was let for final design and fabrication, 

NASA had experts who could constructively criticize proposals as well as 
product. This was essential because ultimately NASA and not the contractor 
had to take the final responsibility for reliability and performance. 

The existence of the professional competence within the agency was 
necessary but not sufficient to explain the success of the program. Im- 
properly utilized, that group of dedicated enthusiastic engineers and 
scientists could have been disastrously frustrated. The question immedi- 
ately arises then as to how this potential intellectual energy could best 
be harnessed. To answer that, we have carefully studied two of the major 
NASA centers responsible for Apollo. We have found two rather different 
management systems operating. From the point of view of this study, that 
is fortunate since project management in Apollo can fruitfully be approached 
through a comparison of the utilization of in-house scientist and engineers 
at the Marshall Space Flight Center (MSFC) and the Manned Spacecraft Center 


(MSC). The fact that there were differences thwarts the tendency for men 
in any organization to accept the structure as perhaps the only way to 
operate. 
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B. COMPARISON OK CENTERS 


Both MSC and MSFC utilized some form of project management but. with 


certain differences,, Particularly noticeable differences were the location 


of sub-system managers and the assigned responsibilities of the Apollo 


program managers at the two centers. There are two important questions to 


be answered In this comparison: (1) Which system provided the better access 


to the research and development or other functional directorates for more 


effective utilization of the in-house technical capability in the program? 


(2) Which system provided the program and project managers with a better 


view of the achievements and weaknesses of the program as it progressed? 


It is difficult to separate the consequences attributable to an 


organizational system from those attributable to the individuals involved. 


A center is a product of its history, the key men, and their capabilities 


as discussed in Chapter II. It is also difficult to isolate effects on the 


program of the experience and competence of the various Contractors and the 


state of the art for the tasks to be done. Nevertheless, as far as these 


can be separated, it is our view that: (1) the system at MSC (Houston) 


provided better penetration of the functional technical directorates with, 


incidentally, less resultant resentment and animosity at the working 


engineer level, and (2) the MSEC (Huntsville) organization provided better 


tracking of the program and its sub-component a. The reasons and the effects 


will be discussed in this Chapter. 


A careful study of MSC, MSFC, and K5»C convinced us that ASF0 at MSC, 


while being in a strong management position, depended heavily on the fune* 








tlonal directorates for the* per f ormanco of real work. At MSEC, the manage* 


ment responsibility for the Apollo program was purposely diffused to Involve 


the line organisation of the Center more directly. At KSC, the APO wan 


essentially a liaison office to bring MSFC, MSC, and Headquarters into 


decisions as necessary, while responsibility for the major task at that 


center was delegated to Launch Operations which was a functional directorate 


of the Center. 


Although we had independently reached these conclusions* we found the* 


substantiated by a recent NASA report in which management was only one 


consideration. A very concise statement of the management systems in the 


Apollo program is to be found in the Report of the Apollo 13 Review Board, 


submitted to the Administrator of NASA by the board's chairman on June 15, 


1970. Appendix E of that long document ia the "Report of Project Manage- 


ment Panel." NASA's adoption of the matrix approach to project management 


for the Apollo program is very succinctly presented. In explaining the 


responsibilities of Apollo managers at the three major centers, that report 


uses subtly different language for the three situations. To this reader. 


that language reflected the real differences found by our own investigations 


of the three centers, as summarized in the preceding paragraph. 


The following three quotations are from that report. The emphasis is 


added by this writer: 


Responsibility for managing all aspects of the Apollo 
Program assigned to the Center is vested in the Manager 
of the Apollo Spacecraft Program Office (ASPO) . . . . 
Virtually all of the Apollo tasks done in-house at MSC 
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. . . are performed by the Center's line organisations 
(the functional Directorates) under the overall direc- 
tlon and coordination of the ASPO Manager. 


MSFC 

Although the Saturn Program Office represents the 
Apollo Launch Vehicle Program Office for purposes 
of full-time management, the Director of Program 
Management has been designated the Apollo Launch 
Vehicle Program Manager. He manages and directs 
ail aspects of the Apollo Program assigned to MSFC , 
drawing on technical support from the Science and 
Engineering Directorates . 


KSC 

Overall responsibility for managing all aspects of 
the preparation, checkout, and launch of the Apollo 
space vehicles is assigned to the Manager of the 
Apollo Program Office (APO) . All functional organi- 
zations at the Center participate in those activities 
under the overall direction of the APO manager. 

Direct responsibility for launch and checkout is 
delegated to the Director of Launch Operations . 

In the management of the Apollo program, the responsibilities of the 
three Center Directors must not be overlooked. In assigning responsibility 
for the launch vehicle to MSFC, the spacecraft to MSC, and launch operations 
to KSC, the Associate Administrator for Manned Space Flight mads the director 
of each center specifically responsible for Apollo Program functions at his 
own center. In actuality, however, the involvement of the Center Director 
and his staff was not the same at each Center and varied with time at the 
various Centers. 

The implications of these organizational differences will be discussed 
further after a detailed look at the utilization of the in-house technical 
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resources at MSFC and MSC and a brief description of the operations at 
fCSC. 

Perhaps the most effective management tool developed in the Apollo 
program was the use of Change Boards. These operated at levels that 
exactly paralleled the management levels in the program, Their purpose 
was to deal with changes in hardware and software proposed or requested 
after design completion. In so doing, the Boards formed a formal channel 
of communication across each Center at various levels and across Centers. 
Because their structure was similar at the three Centers, Change Boards 
will be discussed in a separate section of this chapter. 
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C. CENTER ORGANIZATION AND APOLLO PROGRAM SUPPORT AT THE 
MARSHALL SPACE FLIGHT CENTER (HUNTSVILLE) 


This section and the two to follow deal with the organization of 
the Centers as they existed at the end of 1968. That date represents 
the end of the period of greatest NASA concentration on Apollo. Shortly 
thereafter, all the manned space flight centers experienced some reorgani- 
zation, initiated at least in part by the necessity to provide flexibility 
for the introduction of other manned programs. It will, of course, be 
interesting to take note of the later changes, for instance those at 

drl 

MSFC in February, 1969. This will be done briefly at the end of this 
section. 

The official organization of the Marshall Space Flight Center, as of 
October, 1968, is shown in Figure 1. It is important to note that the 
relationships dealt with here were found to remain essentially unchanged 
when "Industrial Operations" became "Program Management" and the "Research 
and Development Operations" directorate was reorganized into "Science and 
Engineering" and "Program Development 1 ' in 1969. 

In Figure 1, only a few boxes have been filled in and they will be 
dealt with in particular. It is immediately obvious that below the level 
of the staff function offices of the Center, the whole organisation was 
divided into only two directorates. What is not obvious from the chart 
is that most of the Center's budget flowed through the hands of the 1.0. 
directorate, indeed through one program which was the Saturn V office. 
Also, most of the Center's personnel worked under the R&BQ directorate. 
While four programs in 1.0. are represented by the boxes, these were by 































ayirajir/iatucaflia; ' ~agM' 


•• ‘M - 

no means equal in scope nor were they all programs in the usual sense. 

A project manager in the Apollo program has responsibilities to his 
superiors in the line organization of the Center and he certainly has 
responsibilities to the program itself. The apparent conflict of loyalties, 
to the Center and to the Program, is partly resolved when we recall that 
the Director of the Marshall Space Flight Center had been given the respon- 
sibility "for the development, fabrication, assembly, and testing of the 
large launch vehicles required in the Apollo program," Also, the Director 
of Industrial Operations at MSFC was responsible "for conducting and managing 
Launch Vehicle System Projects" and he "acts as the Apollo Program Manager 
at this Center." Both of these men. oversaw other projects as well, but 
they had specific places in the Apollo program organization. 

A generalization frequently encountered in discussions about the two 
directorates at MSFC was that Industrial Operations was essentially task 
oriented, primarily concerned with performance, schedule, and cost, while 
Research and Development Operations was discipline oriented , concerned only 
with performance. This is a gross over-simplification. We have found 
many examples of cost consciousness originating with R&DO personnel, and 
certainly we have found an understandable concern with schedule deadlines 
in addition to a pride in performance in that same side of the house. 
Nevertheless, it is true that the final responsibility for cost and schedule 
rested with the program and project managers, and it was inevitable that 
some of the more bitter conflicts between the two directorates stemmed from 
that formal responsibility which sometimes forced the managers to make a 
decision contrary to the advice of their own in-house expert® who were in 
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R&DO. The existence and indeed the use u£ conflict In the management of 
Apollo is dealt with In Chapter III. 

Perhaps the best way to appreciate the complexity of relationships 
between the two directorates at MSFC is to examine those directorates 
down to their smallest working elements, the sub-system manager in 1.0. 
and the laboratory section in R&DO. For this purpose. Figure 2 illus- 
trates an arbitrarily selected example of a sub-system manager in the 
Engineering function of the S-Il stage (project) of the Saturn V program, 
who may wish to communicate with a quite arbitrarily selected specialist 
in the Environmental Control section of the Mechanical Systems branch of 
the Propulsion division of the Propulsion and Vehicle Engineering labora- 
tory. To trace formal relationships, it has been necessary to identify 
also the Project Support Office within the Systems Engineering Office, 
a staff office in the R&DO directorate. Further, one must note that 
there was a Systems Engineering /Project office within the P.& V.E. 
laboratory. Although ve did not find it referred to as such, this is 
an example of a functional office being "co-located" in another organiza- 
tion, reporting . both to the director of that organisation (the P.& V.E. 
laboratory in this case) and to the parent office (Project Support in 
Systems Engineering) . 

Again to emphasize the complexity of the whole organization, we should 
note the following: 

X. Saturn V was one of four program offices then in the 1.0. 

Directorate. The other© were: 


Saturn I /IB 

Saturn/Apollo Applications 
Engines 
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2. The S-II project manager was one of five project (or stage) 


managers in the Saturn V program. The others were; 


S-IC 


S-IVB 


Instrument Unit (IU) 


Vehicle Ground Support Equipment (GSE) 


Engineering was one of seven stage functions of S-II. The 


others were: 


Program Control 


Test 


Reliability and Quality Assurance (R&QA) 


Manufacturing 


Configuration Management 


Logistics 


4. Three sub-system engineers ate shown on the chart s but in this 


particular office there was al30 a chief engineering manager 


(not shown) . Other offices had either more ©r fewer sub-system 


managers . 


5. In R&DO there were eight laboratories i 


Aero- As trodynaaties 


As tr ionics 


Computation 

Manufacturing .Engineering 
Propulsion and Vehicle Engineering 
Quality and Reliability Assurance. 


Space Sciences 


Test 
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In the P&VE Laboratory there were tour divisions: 

Vehicle Systems 
Propulsion 
Structures 
Materials; 

The Propulsion division of P&VE Laboratory had five branches: 

Engine and Power 
FI u Id-Thermal Sys t ana 
Mechanical Systems 
Applied Research 
Propulsion Systems 

Not shown on the chart is the Projects Office for the Propulsion 
division which had three engine project engineers (F-l, J-2, H-l) 
as well as project engineers for Saturn V, Saturn IB, S-IC and 
S-IB, S-II, S-IVB, and AAP. These were liaison men for the 
corresponding program and project offices in 1.0. 

The Mechanical Systems branch had four sections: 

Advanced Design 
Electro-Mechanical System® 

Environmental Control vi 

Fluid Control I 

Fluid Feed 

Sections , branches , and divisions had chiefs; laboratories had % 

>! 

directors; programs, projects and stages had managers; and all 'I 


these men had deputies and assistants. 
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11. Those were all In addition to all the staff support and functions 
offices that were shown In Figure 1 ami that were quite complex 
in themselves. 

The obvious overlay of program requirements, managed from within 1-0. , 
on the existing a trong line-and-staf £ organisation of the Center's R&D 
laboratories presents a classic example of matrix management. The concept 
of management matrices was not unique to the Saturn V office, but the 
development of such complex matrices, the insistence on their being up to 
date, ...and the heavy reliance on them in day-to-day operation constitute a 
management innovation peculiar to the Saturn V program and represent a 
real contribution to the technique of managing complex technological 
programs . 

The contacts between 1.0. and R&DO necessary in the operation of the 
Apollo program followed both formal and informal channels. For instance, 
no formal agreement for the R&bO laboratories to provide time or facilities 
to a project (which, after all, would require an allocation of funds) could 
be made without the knowledge and agreement of the Projects Support Office 
of Systems Engineering/Project Office located in that laboratory. The 
Change Boards represented another formal communication channel at various 
levels* But since formal agreement for time and facilities allocations 
could be made only after it had been determined what the requirements were 
likely to be, there had to fee informal as well as formal contacts between 
the two directorates and between these two and the contractors at all stages 


of the program. 


The very large number of Individuals in 1.0. who had to communicate 
with various individuals In H&1K) required the construction of formal matrix 
charts to delineate points of contact* For the Saturn V program alone, 
the R&DO points of cgmmitHH?m (persons who could officially commit the 
laboratories for services)* the designated technical persons (who could 
not), the* contractor counterparts artd resident managers, the 1.0* program* 
project, and sub-system managers, all were noted -on 23 separate matrices 
which stated who was officially to interact with whom. 

The telephone was an Indispensable instrument in the whole management 
scheme. The frequency of telephone contact between individuals in 1.0. 
and la R&D0_(as well as between these men and their counterparts at the 
contractors 1 sites and at. the other centers) was unbelievably high. And 
more often than not, these phone calls were by-passing official channels. 

The routes of formal communication , so carefully layed out to ensure main- 
tenance of technical and financial responsibility, were too complex and 
time consuming for a time-critical program such as Apollo. Knowledge 
resides with people despite their office locations. Technical assistance 
and the willingness to expedite a solution with or without official direc- 
tion often depended on mutual trust and respect and on personal commitment, 
dedication, and enthusiasm for the program* Nevertheless, formal documenta- 
tion necessarily followed all agreements or strong disagreements. 

Thus, the Project Support office of Systems Engineering in R&DO com-, 
municated informally with the Saturn ¥ program office, and served as a 
channel for the Saturn V program to get to Operations Management and 
Experiments, which were two other staff offices in R&Dd. Similarly, 


Project Support 4 rail directly wills sub nynt.m manag.ati 


r n 1.0. ami 


with designated or undesignated eng lure ra In t he var ious 


l.ubnrau>i'lca«. 


How frequently did n man by-pm.r: his own utgrr Un’ or the tmperio* 
of a man he. wished to con tart? This depended primarily on their individ- 
ual personalities and style personality . style* and teehoieoi . .impel mice 
©f pro Jcrt manage* s In dealt with in Chapter ill *»4 tltSs t eqnn l H 


depended as well on where a man had worked j' t t v iwuh ly • 


Many nub- system 


managers in 1.0. came from ft&DQ and knew the men they had to t;j IK to very 
well. Thin was an obvious advantage to both parlies. »!«■* laboratory 
manager In comment ing on the move of one of his own ..uboi dl.iaieo to a 


sub-system manager’s position in 1.0* said* "It Is useful to have a 
friendly Indian over there.’ 1 A project oi sub-system manage* who «*ame 
from Industry or another NASA Center (and many did) had the problem of 
penetrating the R&DQ directorate added to his already complex Job. Some 
of these men have commented on the substantial time necessary to estab- 
lish informal contacts. 

One organizational tool that cannot be shown on the fixed organisation 
charts is the use of a "lead laboratory." It was in the nature of all the 


programs at MSFC that many problems either identified in the early stages 
of conception and design or encountered during testing and actual missions 
were likely to cut across the boundaries of the disciplines around which 
the laboratories were organized. When such unforeseen problems arose in 
Apollo, they were dealt with as crises because of the ever-present concern 


with schedule throughout the program. 

For these multi-disciplinary problems, a lead laboratory was desig- 
nated by the director of R&DO. It seems that the selection of a lead 


laboratory depended primarily on die individual chosen to lead the 
Investigation and on his particular affiliation rather than follow- 
ing from the .selection of a logical laboratory, though the two con- 
siderations are hard to separate. The lead laboratory then put to- 
gether a team, primarily from R&DO, and the other laboratories involved 
became supporting laboratories. An engineering manager was designated by 
the lead lab director and each supporting lab designated a project engineer 
for the particular problem. This practice of drawing a working group from 
all concerned laboratories provided the flexibility in R&DO necessary to 
manage the solution of unexpected problems. 

The changes made at MSFC in February, 1969, which have already been 
referred to, were quite significant. They primarily were instituted to 
provide more flexibility in the Center for adaptability to new programs, 
none of which could be allowed to dominate the Center as Apollo, of 
necessity, had clone in the past. Provision was made also for the 
encouragement of the generation of new programs. 

The Industrial Operations Directorate was renamed "Program Management. 
This was certainly a more descriptive term for the situation at that time, 
although it is understandable that "Industrial Operations" had been a 
logical name when the Center's great concern was its relationships with 
industry through contracts that were larger than any government peace- 
time contracts had ever been „ However, the program offices remained un- 
changed in that reorganisation. 

The more significant, change in February, 1969, was the renaming of the 
Research and Development Operations Directorate as "Science and Engineering 


along with the creation of a new directorate called “Program Development. 

The latter essentially took over direction of those functions which would 
lead directly to the conception and development of new programs while 
leaving Science and Engineering in a predominantly supportive role for 
both Program Development and Program Management. Looking ahead to the 
next decade, Program Development (P.D.) provided a much needed home base 
for embryo programs not yet sufficiently developed or funded to be moved 
over to Program Management (P.M.). As a proposed program betame a reality, 
its management could be taken over by P.M. It remains to be seen how smooth 
this transition of each program from P.D. to P.M. will be. 

A fourth Dire-torate, Administrative and Technical Services, was 
created at the same time. It brought together a large number of Center 
staff offices and put them organizationally under a director who would 
be on a par with the three other directors. This took much of the day- 
to-day management of the Center off the shoulders of the Deputy Director 
for Management to free him for consideration of policy matters. It is 
not surprising that, in a year which foresaw declining NASA budgets and a 
general maturing of the whole space program, a Cost Reduction Office was 
created in A. & T.S. Of similar significance was the creation of a new 
Center staff office called Procurement Policy and Review, that function, 
carried out until then by Center arid Program management needed a more 
formal locus of responsibility at the Center level as more programs could 
be foreseen competing for limited funds and making competitive demands on 

contractors. 
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D. CENTER ORGANIZATION AND APOLLO PROGRAM SUPPORT AT THE 
MANNED SPACECRAFT CENTER (HOUSTON) 

The Center organization at the Marshall Space Flight Center (MSEC) 
was described in some detail in the previous section. Therefore here, 
the description of the organization at the Manned Spacecraft Center (MSC) 
can be briefer with concentration on differences between the two. Again, 
the charts shown represent the situation as of the end of 1968, and again, 
very little change in working relationships was found after that date. 

The organization of MSC is shown in Figure 3. In contrast to 
Figure 1 which represented MSFC, this shows five Center directorates. 

Three programs are shown, but they are not in a "Program Management" or 
"Industrial Operations" directorate as at Huntsville. Officially they 
reported directly to the Center Director. 

There were substantial differences between the Apollo Spacecraft 
Program Office (ASPO) at MSC and its counterpart, the Saturn V Office* 
at MSFC. These are evident in Figure 4 in which the organizations of 
ASPO and of one of the functional directorates. Engineering and Develop- 
ment, are depicted to Illustrate program support at that Center. 

While there were under the Saturn V office at MSFC five projects 
or "stages" each with a project manager in charge, the office of the 
ASPO manager at MSC actuaily contained the Lunar Module (LM) manager 
and the Command and Service Module (CSM) manager. The implication is 
that these two men functioned as assistants to the ASPO manager with 
responsibility for their respective projects. Technical management of 
those two projects was accomplished with the aid of the CSM and the LM 
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Project Engineering Divisions aided by Che Systems Engineering Division 
and the Test Division. Parallel I o these four divisions was the Program 
Control Division which played a key role In contract management for ASPO. 

Program Control essentially performed a staff function lor ASPO. 

Each branch chief in Program Control, for instance the LM Contract Branch 
Chief, acted as a "project Officer" for the designated contracts. He had 
sign-off authority on directions to contractors for particular sub-systems, 
but did not make decisions on the technical aspects of change orders. This 
function was necessary because the sub-system managers at MSC, unlike their 
counterparts at MSFC Who were in the project management offices, were to be 
found in one or another- division of the functional directorates such as 
Engineering and Development. Consequently, the Program Control branch 
chief who was a project officer and the sub-system manager in say E&D, 
formed a team to direct the contractor on a particular sub-system. 

Similarly Within ASPO, the individual vehicle managers in LM and CSM 
Project Engineering had "complete authority" for their particular vehicle® 
except for official contract control which resided with the project officer 
(branch chief) in Program Control. 

A very useful function performed by Program Central was the develop- 
ment of cost estimates in parallel with the contractor’s cost estimate for 
any change. If P.C.'s and the contractor's figures were very different , 
there was a strong indication that one or the other misinterpreted the job 
to bs done. This gave an early warning of misunderstanding which, if not 
rectified, could cost the program in terms of both money and time. 
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To pursue the Illustration of program support at MSC, Figure 4 shows 
also the organizational structure of the Engineering and Development (E&D) 
Directorate since this was the prime source of support for hardware develop- 
ment. Within this directorate there was a strong line organizational struc- 
ture under two of the three assistant directors. This differs from the 
organization of the "laboratories' 1 * in ft&DO at Marshall in that the E&D 
Director at M$C is one of five reporting directly to the Center Director, 
while ail laboratories at Marshall were under the R&DO directorate. 

The Crew Systems Division of the Chemical and Mechanical si of E&D 
was chosen to illustrate that a division chief here had several branch 
chiefs under him and that each branch might have several sections or 
offices. Crew Systems was unusual in having an Apollo Branch; only one 
other division of E&D had such a branch. It was in the various branches 
of the eight divisions of E&D that typical subsystem managers were to be 
found. They had responsibility for technical and administrative aspects 
of the management of their own sub-systems, and they generally had their 
own project engineers. However, their authority did not extend to sign- 
off authority in the direction of a contractor; that was reserved to the 
branch chiefs of Program Control in ASPO. 

A few sub-systems in the Apollo program at MSC did not fall specific 
cally into the Of or the CSM projects. The managers of these sub-systems 
therefore reported directly to the ASPO manager and were e&sentially 
project managers with full responsibility for their systems. However, 
they were organizationally located in the functional directorates (as 
wdre all sub-system managers) and stand as an anomaly in project manage- 
ment schemes. 
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While located In a directorate such as E&D, the .sub-system manager 


at WSC had a prime responsibility to ASPO. He was assigned with the 


concurrence of the directorate and ASPO, and could not be removed from 


that responsibility by the unilateral action of either one. Project 


managers to whom he reported could certainly recommend his advancement 


in Government Service rating but his promotion depended on action by his 


own superiors in the line organization of the directorate. He was thus 


tied to the functional organization which was his "home*" and consequently 


his presence there was not likely to be resented. 


Although sub-system managers were far down the organizational struc- 


ture, their location at MSFC and at M5C respectively is a key to the 


difference in the management of the Apollo program at the two Centers, 


At Marshall, sub-system managers Were completely outside the supporting 


laboratories while at the Manned Spacecraft Center, they were nominally 


and actually a part of the technical support group* Both systems have 


their merits and both have disadvantages to be summarized later, 
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E. CENTER ORGANIZATION AND APOLLO PROGRAM SUPPOR T - AT . - . THE 

KENNEDY SPACE CENTER (FLORIDA) 

The organization and operation of the ApoiJo program at. the Kennedy 
Space Center (KSC) is of interest in itself as an example of various kinds 
of project management systems. It is of interest also in what it reveals 
about the differences between the Marshall Space Flight Center (MSFC) and 
the Manned Spacecraft Center (MSC) through their differences in procedure 
at KSC. 

The Kennedy Space Center was not responsible for development of either 
the launch vehicle, which was MSFC's responsibility, or the spacecraft, 
which was MSC's responsibility. KSC developed only what was not peculiar 
to a particular stage of the launch vehicle or to the spacecraft. MSFC 
and MSC could specify what could fee changed prior to launch, hut KSC had 
to say how and when. Thus the launch personnel at KSC, when a revision in 
hardware was required, had to get the developer of that particular component 
to "sign-off” on the change. This would apply as well to hardware developed 
at KSC by one of Launch Operations* sister directorate® such as Design 
Engineering. 

Certain offices in the organisation of ESC a® well as in the Apollo 
Program Office there are shewn in Figure S* afe selected office® for the 
other two Centers have been shown In previous diagrams. 

As might be eKpOcted* stage managers wore found within the Saturn 
Systems office in the Apollo Program Office. These were not in tact the 
equivalent of project managers no the stage manager# had been at MSFC. 

They served primarily as liaison officers between the two centers in all 














matters pertaining to ihelr own hUi^s. The jnirpom* ot tin Saturn Systems 
Office wan to ‘'provide program management and coordination . . «" but it. bad 
no authority to approve. These stage managers did not deal with contfactora 
directly, but worked through MSFC. 

By contrast, the Apollo Spacecraft Office within the Apollo Program 
Office at KSC "provided overall control and coordination . » and "It 
approved KSC commitments Involving Apollo Spacecraft. , . 

The real project managers fot Saturn at. KSC were found In the Test 
and Operations Management (TOM) Office of Launch Vehicle Operations (LVQ) 
under the Launch Operations Directorate. These men could and did inter- 
face with the contractors. Under TOM there is* for instance* tm S-II 
Technical Manager for the S-II contract. The Technical Representatives in, 
for instance, the S-II Section of the Propulsion and Vehicle Mechanics 
Branch of the Mechanical and Propulsion Division of TOM were essentially 
sub-system managers working directly with the $-11 Technical Manager for 
contract direction at KSC. Of the four divisions in LVQ, the Mechanical 
and Propulsion Division was one of three divisions that wore each organised 
according to stages of the Saturn V vehicle. 

The differences in delegation of author Uy snd general style of opera- 
tion was shewn by the fact that HSttt maintained a relatively large resident 
office at KSC, but that office could make no decisions of any substance. 

When a problem developed, MSFC deployed their resources in depth* or as 
one manager expressed it, sent a contingent of MBtC specialists down to 
KSC who "swarmed all over" the problem. MSC on the other hand apparently 
had great trust in one man who was their repregantativh at KSC and who had 
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a snail staff; they did not send relatively large numbers of men from 
MSC to study a problem. By Implication they trusted their contractors 
to solve problems more than Marshall did. 

Internally, to provide the flexibility hot possible In the large line 
and staff organisations of the functional directorates, KSC frequently used 
'Tiger Teams" or task groups, particularly to track changes. A task leader 
would be assigned by one of the managers* for instance in Design Engineer- 
ing, and technical managers would be drawn from appropriate sections of 
the functional directorates. Although some managers were not pleased that 

this had to be done, there was little alternative because of schedule 
pressures. 

While some balance of power was maintained at both MSEC and MSC 
between program management and functional directorates, it would seen? 
that Launch Operations at KSC was much stronger than the Apollo Program 
Office. The opinion was expressed that this power in LQ was created 
deliberately to prevent one program from dominating that center. 


F. CHANGE BOARDS IN THE APOLLO PROGRAM 


Throughout the Apollo program, at Headquarters, MSFC, MSC, and KSC, 
Change Control Boards and Configuration Control Boards were set up in 
parallel to the whole management structure of the program. These provided 
for formal contact across centers, from centers to contractors, and within 
centers at **11 levels. Their employment by the Office of Manned Space 
Flight helped to make the Apollo program a successful undertaking, bring- 
ing together all the resources which otherwise might often have worked at 
cross-purposes. In the same way that the in-house competence of NASA 
provided one of the strongest factors in Apollo, the form and use of the 
control boards constituted one of the boldest and most significant manage- 
ment tools in the Apollo program. 

The point is made in Chapter V that the job of the project manager 
is most active during the period of activity of the major contracts, after 
the basic goals of the program and its components have been set. The pro- 
gram and project managers' jobs would be much less complex if the whole 
program could be conceived at once and no deviations or changes allowed. 
This obviously cannot be achieved in a research and development program, 
so that the major responsibility of management through the contract period 
of the program is to consider, assess, refuse or approve, and track all 
change requests and proposals, in Apollo, this was done by means of the 
Change Control and Configuration Control Boards at the management-levels 






shown: 
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Level 0 Boards NASA Administrator 

Manned Space Flight Office 
MSF Management Council 

Science and Technology Advisory Committee 
MSF Experiments Board 
Apollo Executive Group 

Level I Boards Apollo Program Office, Headquarters 

Level II Boards Manned Spacecraft Center Director 

Marshall Space Flight Center Director 
Kennedy Space Center Director 
Program Managers 
Functional Directorates 
Level III Boards Project Managers 

Functional Directorates 
Level IV Boards Sub-System Managers 

Contractor Resident Managers 
Technical Personnel from Center 
Level V Boards At Contractor's Plant 

Additional Level At Sub -Contractor 's Plant 

While the contract is active there can be many requests for changes 
in detail within the scope of the contract. Occasionally there may be 
requests to go beyond the scope. Both types may be quite reasonable in 
an extremely innovative ptogram continuously pushing to the limits of the 
state of technology. The need or desire for a change may come from the 




contractor, In which case he submits an Engineering* Change Proposal (ECP). 
It may come from within the functional directorates of one of the centers, 
in which case an Engineering Change Request is drawn up. These proposals 
or requests naturally follow lengthy Informal discussions in the critical 
team made up of the sub— system manager, the functional directorate's 
designated technical person in the case of MSFC, the project officer from 
Program Control in the case of MSC, and the contractor's engineer who is 
the counterpart to the particular sub-system manager. There is continuous 
interplay within the team with any one of the members taking the initiative 
usually by means of a telephone call. 

Configuration Control Board directives to implement a change will 
come from the C. C. Board at the appropriate level, established by what 
other elements are affected (impacted) by the change. But these direc- 
tives follow the decisions of the Change Boards after all arguments from 
management, laboratories, and contractors have been heard. 

Naturally, there will be differences of opinion concerning almost 
all changes, and it is not always possible to reach compromises satis- 
factory to every party. It is fundamental to project management that 
the appropriate manager in the program or project office (for levels IV 
and III) or at Headquarters (for Levels II, I, and 0) must assess the 
merits of each argument and make the final decisions. Where a man in a 
functional directorate disagrees at a particular level, the problem can 
be forced to a higher level for decision if the line management within 
that directorate is willing to push it. In other words, whether a 
technical person can pursue his minority report, taking it to a higher 
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level, apparently depends on his ability to convince his own superior 
within the line organization of the directorate in which he works, and 
whether a center pursues an argument up to or beyond level II may depend 
on someone's ability to convince a program manager, the head of a direc- 
torate, or a center director. 

The resolution of conflicts by means of change board reviews pro- 
vided for an active exchange of views among all concerned parties. Appeal 
to a higher level was necessary only where compromises or agreement were 
impossible. To draw an analogy with counter-flow towers in chemical process 
industries: change requests and proposals bubbled up through the organiza- 

tion in such a way that resolvable conflicts were filtered out at each level; 
management decisions cascaded down through the same organization only after 
a thorough evaluation at the highest necessary level; consequently directives 
and requests were never too far from an equilibrium state. 

It is an extremely important function of Configuration Control, at Head- 
quarters and at the Centers, to be certain that each change is properly docu- 
mented, that no affected element in the whole program has been disregarded, 
and that all affected parties are properly notified. In the dynamic situa- 
tion that characterized Apollo, the strength of the Configuration Control 
offices has at times been weak. The importance of Configuration Control 
in the program has been emphasized with each mishap, but its imperative 
position in the program has at times been overlooked. 








G. CONCLUSIONS 


The following conclusions are a summary of our more important 
observations of the project management systems in Apollo with regard 
to the effective use of in-house technical competence. 

1 . Maintenance of a strong in-house technical competence is 
essential in a large, complex, technological program even when the vast 
majority of the budget goes to outside contractors. The great strength 
of project management in the Apcllo program came from the fact that each 
project manager, in dealing with contractors, was backed up by an in- 
house technical competence the equal of which probably no industry or 
government manager had ever enjoyed. Beyond that, NASA’s own people 
had conceived and refined a large percentage of the systems involved 
and could not be misled by others. 

2. The establishment and use of change control and review boards 
at every management level were extremely important in maintaining a 
coordinated management overview of the whole broad program. Through 
these boards all differences could be aired, all changes scrutinized, 
and all concerned parties apprised of progress on difficulties. In 
addition, "management by exception" was possible since differences 
already resolved at one level did not have to be dealt with at a higher 
level. 

3. Center personnel outside the Apollo program as well as those 
officially working in it were equally dedicated to the superordinate 


goals of the program . This made a very, difficult management job easier 
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In fact, It may have made an impossible job feasible. It certainly made 
the whole system somewhat tolerant of minor flaws in the management 
scheme. 

4 . The wh ole Saturn V progra m offi ce a t MSFC achi eved a bett er — 
management overview of the operations for which It was responsible than 
did ASPO at MSC. This was partly a result of keeping the sub-system 
managers in the project management offices, it also followed from the 
deployment of technical expertise in depth in the solution of any problem 
It may have followed from MSFC's inherent distrust of contractors. 

5. The Apollo Spacecraft Program Office at MSC drew more effec- 
tively on the total resources of the Engineering and Design directorate 


without feeding resentments at the level of the working engineers than 
did PM at MSFC. Leaving technical specialists in E&D when they became 
sub-system managers enhanced this relationship without weakening the 
functional organization. At the same time it must be noted that the 
project managers in ASPO at times regretted their lack of direct control 
of sub-system managers. 

6, The delegation of responsibility was more importan t than the 
delegation of authority in establishing a project manager's effectiveness 
within and beyond his own center. In the complex management schemes at 
the three Centers, MSFC, MSC, and KSC, a true project manager could only 
be identified by studying his job rather than his title or his place in 
the organization. 

Matrix management was used with great deliberation and effec- 


tiveness both throughout the centers and into the contractors orgartiza 


tions In the Apollo program. To superimpose this tremendous program 
on the solidly built line organizations of the centers' functional 
directorates and of the contractors required the conception and imple- 
mentation of an extremely complex matrix system. Only through this 
identification of points of responsibility and points of contact could 
the project manager's job be accomplished. 

8. The necessary informal communications must be backed up by more 
formal agreements in all significant decisions. With the necessity to 
bring intelligent judgment very rapidly to bear in innumerable changing 
circumstances , it was necessary in the program to depend on informal 
telephone and direct person-to-person communication. It was necessary 
to deploy manpower before formal authority could be obtained. This was 
acceptable, and in most instances proved satisfactory. In a relatively 
few but significant number of problems, the formal follow-up was not 
sufficiently well documented to prevent later difficulties. Despite 
frequent complaints from technical support personnel that the paperwork 
was overburdensome, it was largely indispensable. 

9. It is a project manager's responsibility to ensure a balanced 
flow of information to himself for the purpose of decision making. It 
must be his responsibility to make a final decision (or pass it to a 
higher level) . Only he can weigh one factor against another and perhaps 
make trade-offs with the overview of his whole project. However, he must 
have the best advice possible from his sub-system managers, the functional 
directorates, and the contractor, and if that is not forthcoming, he must 
force the flow by regular review meetings or any other device. 


CHAPTER V 


the project manager-contractor interface 

by 

Eugene E. Drucker 
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E. Support and Integration Contractors 

F. Resident NASA Organizations 

G. Some Specific Contractor Grievances 
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A. INTRODUCTION 


Quite early in the manned spaceflight program NASA decided that the 
major hardware components required In the program would be procured in the 
traditional way, namely by government contract with private Industry. There 
Is reason tc believe that, permitted to do so, MSFf could have built all of 
the boosters and spacecraft to be utilized in Mercury, Gemini and Apollo. 

Of course, this would have required a tremendous increase in manpower and 
facilities. However, with the in-house expertise and cumulative experience 



at Marshall, there is no reason to believe that the three manned flight 
programs would have been any less successful than they were. 

It has been Federal government policy for many, many years to utilize 
private industry as the main source of procurement, not only for off-the- 
shelf products, but for the bulk of its research and development needs, 
x* was more or less to be expected therefore, that NASA would utilize the 
aeronautics (consequently becoming "aerospace") i r . ' -i.y for the major 
portion of the development and production work associated with the massive 
manned spaceflight program. 

In many respects, then, the procurement of Apollo hardware was similar 
to government procurement of other advanced technological products, mtably 
weapons systems by the Department of Defense. In fact, the DOD system was 
the procurement model utilized by the rapidly expanding NASA organization, 
not only because of the early Army affiliation of the Huntsville booster 
group which made up a large portion of the new NASA space core, but because 
in its quest for manpower, NASA reached out to the DOD for people with 





123 - 


management experience in large projects or programs. 

Unlike the DOD, however, the NASA field centers contained large 
numbers of technical personnel— engineers and scientists from many 
disciplines. At MSFC, these comprised the Army Ballistic Missile 
team under von Braun, and at MSC a large group was assembled around 
a core of NASA’s Langley Field people, such as Gllruth, Faget, and 
Klelnknecht. With-the technical expertise and curiosity of experienced 
scientists and engineers such as these, it was Inevitable that the nature 
of the NASA/contractor interface would evolve into something quite 
different from the DOD/ contractor relationships from which they had 
sprung. If one could loosely characterize the latter as a buyer /seller 
relationship, then the NASA/contractor relationship was more of a coopera- 
tive, team involvement. This is not to say that relations were never 
strained. The team atmosphere was one which only developed after feelings 
of caution and suspicion gave way to mutual feelings of trust and respect. 
It was certainly true in many cases that both organizations were learning 
and one could hardly identify which of the two possessed the "expertise." 

Whether the Apollo program would have succeeded as it did, meeting 
the performance, schedule and cost objectives set up for it at a very 
early stage in the program without the degree of NASA involvement in 
contractors’ affairs which took place is somewhat dubious. The well 
known performance failures and cost overruns in many DOD programs, however 
probably is a reflection of the lesser degree of involvement of government 
agencies in the management of industrially contracted programs. 
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It has been amply stated that the NASA project manager has working 
relationships, or "Interfaces" with several groups of people. In the 
previous Chapter, the internal relationships at the Field Centers have 
been examined in detail. 

The assessment of the relative Importance of these interfaces Is 
a difficult one to make. Therefore, It Is best to avoid the argument 
of whether the contractor Interface Is more important to the NASA project 
manager than his other interfaces. Clearly, though, in terms of actually 
designing, fabricating and testing hardware systems and individual Items, 
the success of the project is directly related to the performance of the 
contractors. In no small part, the performance of the contractor In turn 
is strongly influenced by the NASA project manager; that is, by his sug- 
gestions i reviews, and his ability to modify contract specifications and 
to change the amount of resources made available to the contractor. The 
key nature of the interface is "change." Indeed, if the conduct of a 
NASA contract were very routine the function of the NASA project manager 
would be little more than clerical monitoring. And under these circum- 
stances, there is no reason to believe that NASA could continue to enjoy 
the affiliation of technical and managerial personnel of clearly superior 
competence to that of most other governmental agencies. The nature of 
development projects, which by and l^rge most Apollo program contracts 
were, is such that constant communication between contractor and contractee 
is necessary if a reasonable compromise between performance, schedule and 
cost Is to result. Otherwise, almost any specified performance may be 
obtained given sufficient time and money* 
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The handling of changes requires a certain formality to satisfy 
contractual requirements and to provide the very basis ol a workable 
configuration control system. In the case of a completely in-house 
NASA or industrial company project, the formal requirements are mini- 
mized* But with the sxpendlture of large amounts of public funds and 
the responsibility for flight safety, the formal necessities are con- 
siderable, and correspondingly time consuming. Were the Apollo changes 
to rely solely on formal channels however, there is no doubt that the 
Program would have extended over many more years than have actually 
elapsed. Nevertheless, despite the heavy consumption of time and 
effort, the complaints of industrial contractors, the comic portrayal 
of the paperwork overweighing and overshadowing the hardware, pain- 
staking documentation of changes to hardware and software is the only 
known method to insure control of a complex engineering system. 

In the end, a NASA/con tractor interface consists not of a series 
of communications, encounters, and disagreements between two organiza- 
tions, but of a myriad of people, pairs or triads who engage in various 
oral and written communications or information exchanges. So, although 
contractually there were only a small number of designated personnel 
who could issue orders or "sign-off" on official, legal documents, the 
actual NASA/contractor interface consisted unofficially of a large 
number of people in both organizations who had hourly, daily or weekly 
contact with each other. 
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B- THE NATURE OF THE NASA/ CONTRACTOR INTERFACE 


The basis for the NASA/Contractor interface Is a contract, which 
defines In a legal way the mutual commitments and obligations of the 
two parties, such as the hardware, software or services to be produced 
and delivered by the contractor, and the resources (funds, tools, build- 
ings, plants, etc.) to be provided by the government. By "interface" 
is meant the entire set of contacts made by various members of the two 
organizations. Of course, it Ls true that substantial discourse may be 
hr.d between the two parties prior to the execution of a contract, i.e. 
during its negotxation. However, it is the contract period which is of 
primary interest, as far as the role of the project manager is concerned. 
The relations between the NASA project manager and his prime contractor 
undergo distinct changes with time for two reasons. One is purely a 
humanistic proposition; there is a learning curve necessary for people 
to learn about each other and each other ( s organization and method of 
operation. Naturally, relations are more reserved and formal in the 
beginning. With time, however, in most cases, a more informal relation- 
ship develops which is more of a partnership than a vendor-customer nature 
because of the phenomenal appeal of Apollo to all concerned. With most 
other government procurement operations, though, the latter format is 
retained throughout. 

Secondly, there are different requirements and emphases as the work 
progresses through the different phases of concept definition, design, 
manuf actui ing and testing. For example, schedule establishment and cor it 
estimation is very difficult in the early phases, becoming less of a 
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problem— a.t the end of the contract cycle when schedule-maintenance and 
cost control problems predominate. The fact that different contracts 
may be in effect for Phases A. B, C, and D is of minor consequence, 
since the same contractor usually is engaged for all of the phases. 

The nature of problems and subject matter discussed and acted upon are 
quite different in the concept phase than in the manufacturing phase, 
for example. In the former case there is significant communication in 
terms of predominantly technical matters, that is, of matters based on 
engineering or scientific information which affects the working or per- 
formance of a piece of hardware, a computer program, a flight plan, and 
so forth. In manufacturing, on the other hand, major concern shifts 
toward industrial matters: delivery schedules, minor engineering changes, 

quality assurance and check-out procedures. Not only does the subject 
matter of the NASA/contractor interface change with time, but different 
people, in both organizations become the centers of action. This is true 
despite the fact that the NASA and the contractor project managers always 
have the nominal responsibility for all facets of the conduct of the 
contract. 

NASA/contractor interface activity generally takes the form of 
action items requiring NASA decisions, on the part of the NASA project 
manager. It is very convenient and indeed quite common to think that 
his responsibility and therefore his decisions can be neatly divided into 

technical, schedule and cost categories. 

"Technical" decision implies a decision based on engineering or 
scientific information which affects the design or operation of a piece 
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of hatdWare, computer program, or flight plan# There Is no doubt that 
the three elements, performance, schedule and cost exist and are Identi- 
fiable in most actions. But they are rarely, if ever, independent of 
one another# A "techrical" decision can never be made without consider- 
ing its influence on cost or schedule. It may have no influence, but 
certainly the project manager must think about it and make a judgement 
in the matter. Similarly, a change in schedule can seldom be made with- 
out any impact on cost and often performance. 

Rather than trying to identify a decision as "technical", "schedule", 
or "cost" according to the major subjective content of the problem, it 
is perhaps more rational to indicate the type of problem and decision by 
its origin. The need for a decision arises when a problem materializes 
and one of several alternative solutions must be chosen. The problem 
will commonly be of the nature of an indicated failure to meet perfor- 
mance specs, a schedule slippage or a potential cost overrun. These 
are clearly identifiable by source, but the solution to each (or decision 
making) will surely involve all three classical elements. Decision making 
is nothing more than the selection of one of alternative solutions. The 

function of the project manager is to examine and evaluate the alternatives (f 

I 

and make the most rational choice. The manager has staff personnel who 
gather and prepare basic information concerning performance (systems 
engineer, sub-system manager, or R&D liaison person), schedule (program 
control) and cost (contracts and pricing) . This does not imply that 
program control is concerned only with scheduling; it performs several 
other important functions as well. 
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Managers have various degrees of familiarity with the technical 
details of their project, depending upot the nature of the individual 
and to some degree upon the historical philosophical tradition of the 
particular center* For the larger projects and systems, it is literally 
a physical impossibility for a project manager to be Intimately familiar 
with every detail of every sub-system in the project. He must there- 
fore-raly upon his sub-system managers, resident office managers and 
contractor representatives for processed rather than raw information. 
There is, thus, no systematic way for the project manager and his 
contractor counterpart to avoid wrong decisions, as in the case of the 
Apollo 13 oxygen tank failure, when incomplete or erroneous information 
is provided to them. 

In matters of t lical origin, the MSFC project manager relied 
very heavily on the in-house R&D people for engineering evaluation. 

His activity has been characterized aptly as a "lateral management," 
as a Chairman of the Board, as a mediator of the technical laboratory 
representatives and perhaps more of a coordinator than an independent 
decision maker. Contractors consider this style to be a consequence of 
the strong laboratory orientation of Huntsville, in turn a historical 
institutional development, by no means devoid of personality factors. 

As far as the contractor is concerned, this managerial style makes for 
a lengthy decision making process, but also a carefully considered one. 
This is so because the style is dependent upon the concurrence of many 
people. 
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The strong project management style, In a rather general sense, 
is characteristic of MSC project management. Inherent in this general- 

i 

ization is the danger that the style attributed to the Center is in fact 
a reflection only of one or two individuals at MSC. Regardless of the 
underlying causative factor, however, the empirical observation of 
contractors and researchers alike is that the MSC manager sits astride 
a pyramidal organization, takes more of the decision-making responsibility 
upon himself. This may require, or it may follow from a greater partici- 
pation of the manager in the technical details of the problem and its 
solution. 

A point of similarity between both Centers and the contractors is 
the technique of the CCB f s (Configuration Control Boards). All organiza- 
tions have parallel CCB’s at different program levels. Engineering change 
proposals (ECP's) are processed more rapidly at Houston than at Huntsville 
because of the greater degree of centralized project management at the 
former center. 

Given the dependence of the project managers (both NASA and the 
contractors) upon the subsystem managers, the effectiveness and thorough- 
ness of the latter are obviously of the greatest importance to the success 
of the project. A large degree of responsibility and authority assigned 
to the sub— system manager tends to sharpen his motivation. The rigidity 
of the Apollo time schedule tended to foster strong centralized control 
and decision making, in some cases with an adverse effect on the morale 
of the subsystem manager with laboratory orientation. Permitted a some- 
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C. CONTRACT NEGOTIATION 

It is the NASA project manager and his contractor counterpart who 
have the responsibility for making program decisions, but only the 
contracts or procurement office has the legal authority to translate 
these decisions into contractual documents, or changes thereto. In 
their anxiety to get the job done, verbal authorizations have been 
given to contractors by NASA project personnel in many cases. Although 
most of these work modifications or additions were honored by subsequent 
written authorizations by appropriate contracting offices, there were 
some cases early in the program in which contractors could not recover 
their costs because of the insistance of some NASA contract officers 
on prior NASA written authorization for the contract change. 

It has been a frequent complaint that the NASA legal procedure for 
contract change is time consuming and therefore tends to restrict tech- 
nical improvements and innovation. However, the formal procedure assures 
several important consequences: 

1) that the indicated change enters the configuration control 
system 

2) that the change is made known to many other persons who can 
view it in terms of impact on other systems, 

3) that suggested changes not in consonance with the established 
budget or financial resources are avoided, 

4) that since the indicated change is scrutinized by others, its 
justification by the originator must be well thought out and 
strong. 
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Therefore, despite the frustrations and Impatience of dedicated 
engineers, quick verbal requests for changes or additions by sub- 
system managers, engineering laboratory personnel, resident engineers, 
astronauts, etc. should not be honored by contractors. Since, in the 
technical world of NASA, decisions and negotiations are of a highly 
sophisticated nature, and since contracting personnel are generally 
not engineers by background, there tends to be a natural communication 
and understanding barrier between project manager and contract adminis- 
trator. This is not to say that the barrier is insurmountable; it is 
simply inherently there. 

At MSFC, the Contracts Office is not a subdivision of the Apollo 
Program Office, but is an independent staff or functional group of the 
conventional procurement type. The manager-contract administrator rela- 
tionship therefore tends to be somewhat formal and somewhat far apart, 
and the process of translating program needs into legal documents tends 
to be lengthy and needful of better coordination. 

At MSC, the contracting and technical people have a less formal 
and more closely allied relationship, and as one contractor respondent 
aptly put it "are closely in bed with each other." The NASA contract 
people participate In technical negotiations between NASA and Contractor 
managers, a practice not followed at MSFC. As a result of the close 
liaison there generally is quicker contract action. Organizationally, 
this takes place through the Contract Engineering Offices, which are 
jointly responsible to the Program Office (via Program Control) and to 
the Director of Program Control and Contracts on the staff side of the 
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house. This is a practice which is innovative and very much appreciated 
by contractors. This feeling is illustrated by the statement of a 
Contractor Executive who had had experience with both Centers; "1 have 
never yet had a verbal commitment out of Houston sitting in this office 
with the contracting people and the technical people that wasn't lived 
up to by the contracting people." By implication, there were experiences 
with Huntsville in which, at the very least, there were difficulties with 
NASA contract follow-up of prior technical agreements. 

From the point of view of NASA, it was pointed out by an MSC co- 
located person: "We think we benefit by our direct association with 
the program office. There's no question as to where your primary 
functional interface is located and we feel that we occupy a more prestige 
position in dealing with the contractor. . . .But in dealing with defense 
contractors they always tend to focus in on where the power lies. . . • 

And in a development program, R&D, the power should lie in the program 


office." 
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D. CONTRACTORS' ORGANIZATIONS 

The contractors are tor the most part organized around lines similar 
to the MSC and MSFC "matrix" organization. Virtually every contractor has 
indicated that NASA has had some Influence in bringing this about, although 
to many, this organizational form was not new. NASA liked to see a strong 
program office utilizing fully the functional resources of the company. 

Some contractors resisted but all seemed to have evolved a strong program 
office, ironically, these contractor program offices appear to be considerably 
stronger than those in NASA itself, the very stimulant to the emergence of 
the aggressive, action-oriented management format. There undoubtedly also 
has been some influence on the NASA organization by contractors, but this 
is much more difficult to assess. 

The notion that the NASA and the Contractors’ program offices have 
corresponding or counterpart positions is widespread in NASA. However, it 
was found that the Contractor’s program manager in general does not have a 
single counterpart in the Space Agency, in spite of efforts to bring this 
about. The desirability of counterpart personnel throughout the affected 
organizations is clear, in that it. makes obvious points of contact and 
promotes ease of communication and pinpointing of responsibility. It was 
found, though, that there is an overlap, rather than a clear cut matching 
of responsibilities. Correspondingly, it was indicated that particular 
contractor managers had several alternative points of contact in NASA, at 
different authority levels. This is particularly conspicuous at MSC, where 
despite the official designation of only one program manager for Apollo, 




there are assistant and subordinate persons whose responsibilities although 
not titles, correspond closely to those of a project manager. 

There appears to be no really Important reason, ether than symmetry 
of the organizations, why the objectives indicated above could not be met 
without one to one correspondence of positions. The problems faced by a 
NASA program office and a contractor's program office are by no means the 
same (as will be discussed later) and therefore there is no compelling 
reason for the organizations to be the same. 

It is understandable that each NASA project and sub-system manager 
desires to see his Contractor's manager occupy a position of great authority 
within his Company. This insures the assignment of a generous share of the 
Company's resources to the project involved and a high standing on the 
Company's priority list of in-house work. However, the strength of the 
Program Manager within his Company depends on the relative value of the 
Contract to the Company, measured not exclusively in dollars but in terms 
as well of the future potential of the product concerned or the technical 
capabilities acquired. Some of the Contracts were so large and important 
that the Program organization quickly assumed the actual, but generally 
not titular, status of a separate division of the Company, physically not 
continguous to the Company and having most of the staff support usually 
associated with a parent company. A good example of this arrangement is 
the SII Stage Program, conducted by the Space Division of North American- 
Rockwell Corp. at its separate facility in Huntington Beach. 
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On the other end of the spectrum, where there are several projects 
of relatively small and equal size, the company resources are economically 
distributed to the project In the recently designated "matrix form." That 
is, the several projects draw on functional services of Company Departments, 
and personnel have joint responsibility and loyalty to both programmatic 
and functional organizations. In contractor parlance, this process is 
known as "projectization." This format Is particularly well adapted to 
handle the early stages and the phasing out of projects. Since functional 
support can be provided In continuous Increments (such as .25 or .75 of a 
man), It can be provided according to need and it can change relatively 
rapidly. If a project grows to the size of a LM or S1I, then It In essence 
becomes a "company within a company" and the advantages of projectlzation 
are not as obvious as they are with smaller projects. 

Industrial project organizations go through a life cycle, as depicted 
on Figure 1, starting with a small research group developing a technical 
concept. If the concept survives and is funded, a project team is assembled 
In a matrix format. If the project continues on and grows, it may become 
the dominant project office In the matrix and ultimately achieve a Division 
status, such as Atomics International, Rocketdyne and Autonetlcs in the 
North American-Rockwe.ll Corporation. 

The growth of a project may be arrested and even reversed at any of 
the stages described above. Typically, many of the projects existing at 
the matrix stage, with more or less equal magnitude and importance, will 
not grow beyond that level cud will phase out sooner or later. A similar 
fate will befall most dominant programs, either directly or going back 
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through the matrix level. Faced with the practical necessity to economize, 
waning projects or Divisions are consolidated. Inevitably, the specializa- 
tion and expertise assembled in the growing project or Division is quickly 
dissipated during phase— out. Recognition of the stages of project metaphorsosis 
should be an Important feature of NASA decision making With respect to 
industrial contractors. 

The history of a "project” does not, therefore, appear to be always 
describable as the simple combination of a creation, a work, and a phase-out 
process. The project has a life cycle, starting from and often ending in 
stages which are organizationally quite different from the "adult" phase of 
the project. By this is meant the matrix stage, in which most of the unique 
£eaturjes_jQf_project organization are manifested. At stages before and after 
this one, the difference between project organization and ordinary organization 

are rather indistinct. 
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E. SUPPORT AND INTEGRATION CONTRACTORS 

In addition to the development and production contractors who were 
engaged in Apollo hardware and software* a number of other Contractors were 
engaged by NASA to provide a variety of support services to the Field Centers 
and particularly to the ASPO in Washington. In most cases, these contractors 
were extensions of NASA itself, performing technical consulting services and 
management information services such as the maintenance of the Apollo Action 
Center in Washington. 

The Boeing Technical Integration and Evaluation (TIE) contract was 
concerned with the control of technical interfaces and configuration manage- 
ment. Because of resentment towards and suspicion of an outside organization 
by field center and prime contractor personnel, however, the contract was 
largely ineffective. In addition it was difficult for a new organization 
coming into the middle of the program to assimilate all of the background 
of the extremely complex Apollo enterprise. 

While supportive, staff-type work by industrial contractors appears 
to be useful to and harmonious with NASA personnel, the assignment of a 
supervisory role, whether actual or apparent, to a private company has 
little chance of success in the NASA environment. 











F. RESIDENT NASA ORGANIZATIONS 


Intermediate between NASA Field Center Program office and prime 
contractor Is the resident NASA office. The resident manager is intended 
to be an extension of the NASA program or project manager at the contractor's 
site. His role is to maintain close contact with the contractor, and to 
expedite the progress of the contract by making certain classes of decisions 
on the spot in behalf of Field Center managers. 

As a natural consequence of the differences in project management 
organization and authority at the two NASA field centers, the resident NASA 
personnel at the Contractor sites also exercised correspondingly different 
degrees of authority, although in terms of the charters of the resident 

managers, the differences were not large. 

The MSC RASPO (Resident Apollo Spacecraft Program Office) is directly 
responsible to the Apollo Program Manager in Houston, although the LM and 
CSM managers possess some functional authority over the resident • 

In the case of MSFC, resident management offices (RMO) were attached 
to both the Saturn and the Engine Program Offices, received their principal 
authority from individual project managers rather than the program manager, 
but were in the sensitive position of also having to represent the MSFC 
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Laboratory Directors. Despite the explicit instructions in tie RMO 
charter, however, the dual responsibility of the Resident Manager to the 
10 and R&DO sides of the house was often ambiguous or incompatible. This 
accounts for the greater difficulty that the RMO's had in operating than 
the RASPO's and as a consequence i he greater effectiveness of the latter 
over the former on site. 

The role of the resident office is an unusual one in an organizational 
sense. Obviously, the office's primary role is to act as a representative 
of the center at the contractor's site, but in addition the resident office 
must, in order to be effective, become the contractor’s ally and confidant. 
This is indeed a difficult role, and not surprisingly leads to many of the 
resident manager's dilemmas. 

The resident office also acts as the communications link between the 
center and the contractor. It is through the resident office that all 


^"These (RM) offices are an extension of MSFC program management, 
established to assist in the execution of the MSFC mission by providing 
on-site representation. In this role, the Resident Manager projects the 
on-site MSFC /NASA image and is the official on-site spokesman for the. 
Center. His office is the official channel of communication between 
MSFC and the contractor. Every effort must be made to strengthen the 
Resident Office by working through the office and in particular through 

the Resident Manager. 

The Resident Manager is responsible to MSFC through both line and 
functional management channels and must represent and satisfy all MSFC 
interests. His principal responsibility is to the Program and Project 
Managers. He must, however, also assure the effective execution of all 
other on-site functions and, consequently, must satisfy all MSFC functional 
managers. In each functional discipline, business and technical, he must 
asst re accomplishment, communications and execution of functional policies. 
It is the responsibility of each MSFC manager; i.e., Program Manager, 
Project Manager, Lab Director, Contract Office Chief, etc., to clearly 
define his resident requirements and communicate them to the Resident 

Manager . " 

MSFC Management Policy Statement #3 (Revised), August 29, 1966. 
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official correspondence flows. This means that the resident office becomes 
actively Involved in any contractual changes; a very Important role. 

Two other roles played by the resident office which are less tangible 
than the others, but which are nonetheless significant to the NASA-contractor 
relationship are: 1) the development of mutual respect between NASA as a 

whole and the contractor; and 2) the role of keeping the contractor alert. 

Of course, the former may backfire if the contractor-resident manager inter- 
face becomes abrasive, and a mutual disdain may result instead. 

Without doubt, it is this wide divergence of roles which makes the 
resident manager's job sensitive, difficult and at times frustrating. 

The establishment of large resident offices early in the program 
understandably aroused the suspicions of the contractors, despite their 
previous experience with on site government personnel via DOD contracts. 

In prior instances, though, concern for the most part was for quality control, 
inspection and product acceptance purposes. 

With the Apollo contracts, where the contractor's work was of a highly 
developmental nature and schedule maintenance and extreme safety consciousness 
was especially important, the NASA resident personnel played a more intimate 
role in the contractors' affairs than ever before. It is not surprising that 
the contractors felt that they were living in a closely monitored, transparent 
environment, entirely alien to the normal concepts of company-customer 
relations. 

The feelings of animosity created in some Instances by the two organiza- 
tions being thrust together could be and were dissolved to various degrees by 
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efforts primarily on the part of the resident manager, since in a sense it 
was he who could be considered the alien member of the association. A sense 
of mutual trust is reached in time when there is professional respect and 
complete open-handedness between the resident manager and the contractor 
manager, and when the latter becomes convinced that the resident office 
can be helpful to him in accomplishing the objectives of the contract. One 

contractor manager interviewed said: 

At first our Company was dismayed and alarmed at the 
amount of on-site customer participation. .. the most 
significant aspect of that thing which is mutual 
trust and the realization that it was absolutely 
pointless to try to play any set of cards close to 

the vest. 

Easily detectable here is the feeling of early alarm but subsequent and 
not altogether unhappy resignation to the situation as it exists. 

In what way is the resident manager useful to the contractor? The 
resident manager is in almost constant communication with the contractor, 
and is, therefore, aware of problems immediately as they arise. He is 
capable of bringing these problems to the attention of the center project 
manager, not for punitive purposes, but to seek technical or financial aid 
or authoritative support as necessary. The resident manager can often 
expedite certain center decisions which the contractor is waiting for. The 
resident staff can also identify problems which can be corrected at early 

stages. 

In its attempt to keep informed of contractor progress and to input 
guidance and technical direction to the contractor’s work, resident NASA 
personnel of the KMO or RASFO staff, or more usually, laboratory representa- 
tives can easily overstep the bounds of their contractual authority, and 






- 145 - 




overpenetrate_ the contractor's organization. There Is little chance for 
a congenial relationship to exist under these conditions. 

The problems discussed here are really part of the overall task of 
establishing a viable working environment between the resident office and 
the contractor. They are the most important problems that face the resident 
manager in dealing with the contractor. Without solutions to them, the 
usefulness of the resident office to NASA would be very questionable. 

Equally essential to the viability of the resident offices is the 

maintenance of proper relations with the Centers. The main problem which 

must be avoided is the undermining or ignoring of the resident manager's 

authority by Center personnel, who may by-pass the resident office and 

deal directly with the Contractor, thereby placing the Contractor in an 

uncomfortable position as well. Resident office charter notwithstanding. 

Center project or functional managers may simply refuse to delegate certain 

authority. This was concisely put by a contractor representative: 

1 would say that the problem that had been most severe 
would be the amount of authority that we could construe 
that has been placed in the office. Now NASA and we have 
exchanged contractual documents which said he has the 
authority to do this and this and this and this. But 
there is one thing, to look at the printed word and then 
say now let's get into a specific thing. 

The only way for the resident manager to combat this tendency is to 

vigorously assert the authority which has been delegated to him by the 

Center Director, with the full backing of the Director being virtually 

assured. 

The inability or lack of desire of the RMO organization to obtain the 
necessary delegation of authority is one of the reasons why the RMO organiza- 
tion appears not as effective as the RASPO organization. Reading between 
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the lines of Management Follcy Statement #1 ami a contemporary agreement 
between 10 and R&DO directors, it is clear that early in the program the 
Huntsville program/project managers generally did not delegate suff relent 
authority to their resident managers and never insisted that all official 
communications go through the resident office. 

Ironically, close cooperation with his contractor may alienate the 
resident manager from his Center, appearing as it might that the resident 
had "sold out" or was assimilated into the contractor's organization. Given 
compatible personalities and lengthy on-site service, it is quite possible 
for a strong alliance to develop. For example, a contractor representative 
said: 

There have been many instances where they have done 
things for us that I am sure have enhanced our ability 
to get certain decisions made because, let's face it 
they are closer to us than they are to their own 
people. 

He also felt that Center management preferred to deal directly with the 
Contractor because of the lack of trust in the resident office. 

The view expressed by the above interviewee was by no means a 
unanimous one. Some contractor people f elt they could manage nicely without 
resident offices at all. 

Interface problems are discussed in greater detail in a NASA/SU Working 
paper by Barry L. Kelmachter, "The NASA-Apollo Contractor Interface: The 
Resident Management Operation," Working Paper #24, Syracuse University, 
February 1970. 
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The clear consensus of the NASA Interviewees Is that troublesome as 
relations have been with Contractors and with Centers alike, the resident 
offices have performed a significantly useful function in the Apollo Program. 
And despite many specific complaints, the contractors, freely or grudgingly, 
have by and large acknowledged this assessment. Because the RASPO's operated 
from a center with less Internal conflict between programmatic and functional 
organizations, they could and did represent their Center with greater 
effectiveness than the RMO's. They obviously enjoyed more authority, made 
more on-site decisions, and consequently had a closer relationship with the 
contractor. Those contractors who have had experience with both Centers 
indicated preference for working with the RASPO's rather than the RMO's. 

This is surprising to some degree because RASPO is considered to be more 
demanding in their monitoring functions than is RMO, but at the same time 
it verifies the Importance of good resident-contractor relations in maintain- 
ing an effective resident office. 

The most important period of the development and production cycle for 
the resident office is that which takes place between the completion of 
concept and preliminary design work, and the last production runs. This 
was especially true in the Apollo Program where schedule pressures were 
very great. It is the period where efficient communication between Center 
and Contractor is absolutely necessary to make schedule mileposts. 

Given smaller projects with less demanding schedule restraints, then 
the necessity and utility of resident offices beyond QC and acceptance 
duties may become marginal. 
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G. SOME SPECIFIC CONTRACTOR GRIEVANCES 

It is inevitable that the forced intimacy of a public agency anl a 
private corporation will produce certain tensions, points of friction and 
irritation* After all, there are substantial differences in motivation, 
tradition and style between the two organizations , as discussed In the next 
article* 

The conclusion of the previous article is well worth emphasizing here; 
namely, that the general nature of the NASA-Contractor relationship is not 
only satisfactory, but has helped more than hindered the achievement of 
program objectives while fully protecting the public interest. The complaints 
made by the contractors should be viewed against this background, and perhaps 
considered as suggested areas of potential improvement in the NASA-Contractor 
mode of operation. 

1. There is excessive monitoring on the part of NASA, and undue 
penetration into the internal affairs of the Company* This is partly due 
to a well meaning, paternalistic attitude on the part of NASA toward its 
contractors, partly to the extreme schedule pressures in Apollo, partly 
on the desire of NASA engineers to head off problems and to see their own 
ideas and expert knowledge incorporated into contracted hardware and software. 
Nevertheless, it creates in the contractor organization a "goldfish bowl complex." 
Monitoring activities have, of course, decreased as projects near completion. 

2. There is a general feeling that NASA is overmanned at the resident 
office level. Because the contractors are producing hardware and software, 
they tend to think of themselves as the "doers" and NASA as the monitors 
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and administrators to a large extent. The necessity of phasing out 
contractor personnel toward the end of the program, but not resident 
personnel contributes to the feeling oi surplus NASA manpower. 

3. There are excessive requests by NASA for Information, briefings, 
proposals, etc. as a result of the excess of NASA manpower over needs. 

The tendency to have meetings Increases In Inverse proportion to the amount 
of work that people have to do. At the same time that pressures on NASA 
personnel are relaxed, the work load on contractor personnel tends to 
increase in view of the phasing down of manpower toward the end of the 
contract period. This accentuates the time demands placed on contractor 
personnel by NASA in the final project phases. 

4. There is seme ambiguity in NASA management, compared to a company's 
clear lines of authority. Whom to go to to get particular decisions? Who 
is authorized to require the contractor to make changes? There is a whole 
spectrum of changes, from those lightly suggested by intermediate level 
NASA people to those demanded, authorized and contracted for by top level 
NASA managers and contract officers. On the surface, this ambiguity does 
not appear, because in a legal sense there is a formal, well defined 
procedure for bringing about not only hardware changes, but schedule, cost, 
contractor personnel and other changes as well. However, one cannot ignore 
the intangible effects on contractors of suggestions and requests specifically 
voiced or implied by NASA representatives from various organizations. For 
example, although many contracts are funded and monitored by Centers, much 

of the authority for approving the contracts, changing them, renewing them, etc. 
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lies in Washington. Therefore, the contractors find it difficult to 
resist their natural tendency to satisfy various members of the Headquarters 
establishment. Directions thus Indicated sometimes caused conflict with 
Center or project managers. 

5. Contractors sometimes were caught in the middle of an inter or 
intra-center dispute, very much like the resident managers. In particular 
certain NASA internal personality conflicts, which have been difficult to 
keep concealed, have had adverse effects on some contractors. 

6. Ordinarily, hardware in production at a contractor plant is 
subjected to quality control checks by both plant personnel and NASA 
resident QC personnel. In some cases, however, other federal agency QC 
personnel are utilized in a plant at which other than NASA projects are 
also in progress. These might be Army, Navy or Air Force civilian QC 
personnel, who are responsible directly to their own agency supervisors, 
although they are representing NASA in their relations with the Contractor. 

In effect, then, there are three parties involved in QC affairs in the plant, 
flnH since many of the QC judgments which must be made on the floor are 
subjective in nature, a good deal of friction can easily be generated. 

7. NASA does not designate a chief engineer in their own management 
organization, as industry invariably does on a project or program. It is 
true that the NASA project manager was himself in many cases the chief 
engineer, in effect. During the life of the project different people at 
different times performed the functions of chief engineer. In industry, 
the necessity for separating the functions of program manager and chief 
engineer are clear. The manager has many areas of concern other than the 
strictly engineering one, and cannot deal in the fine details of the project. 
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The NASA manager, on the other hand, has fewer business and personnel 
problems, and can deal In greater depth in engineering* Then again, the 
amount of engineering work done is much less in the NASA project group 

than In the much larger contractor group. 

These considerations are further amplified in the next article and 
lead to a partial mis-match of the roles of the NASA and the Contractor 
project managers. 

The designation of a single chief engineer i" a large NASA project 
organization appears to be a desirable modification of NASA practice, 
because it frees the project manager to deal with broad project matters 
and presents an unambiguous technical liaison point for the contractor. 
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H, SOME POINTS OF COMPARISON: NASA & CONTRACTOR PROJECT MANAGEMENT 

There are a numb er of similarities between NASA and Contractor project 
management, but more importantly for their impact on the NASA/Contraccor 
interface, there are salient differences. Some simply require recognition, 
but others form the roots of problems or at least of contractor grievances 

as described in the previous article. 

1. The contractor’s fundamental motive is profit, whether it be direct 

or the acquisition of an expertise and experience base from which other 
enterprises may be launched. This is not to deprecate industry, on the 
contrary, the indirect motive is the very vehicle by which NASA-funded 
technological developments are most effectively transferred to the 
industrial community. 

Obviously, NASA’s function is not to earn money but to insure the 
meeting of performance and schedule goals set in the early stages of each 
project. While project managers operate under money constraints, they are 
generally less concerned with effecting economies than they are with obtain- 
ing the greatest performance and reliability of their hardware in a given time 

While there is no conflict between NASA and contractor by virtue of 
basic motives, these do influence the general philosophies of the two groups. 

2. The contractor's major problem areas are detailed design in the 
early phases; manufacturing, labor, union and associated difficulties in 
the latter project phases. In the early stages of most project developments, 
the NASA manager often participates in technical evaluation and critique, 
but as the project matures, his concerns shift to scheduling, supplementary 
funding and controlling changes. Thus, the roles of the NASA and contractor 
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managers are not the same and they diverge to some extent with time. The 
managers are therefore not ’’counterpart" in the sense of performing similar 
or parallel tasks, but are complementary to each other and act more as 
members of the same rather than competing teams. 

3. The Contractors' program organizations are strong and highly 
pyramidal in shape, at least in the case of major prime contractors. NASA's 
influence in this direction has been large, but by the nature of private 
enterprise, supervisors have more authority over subordinates than in public 
service (with the exception of military and police types of functions) . 

The NASA program organization appears to be weaker in terms of line authority, 
having the nature more of a coordinating, monitoring and advising group. 
However, there are exceptions; there have been particular project managers 
who were highly authoritarian, even bordering on dictatorial. 

4. Contractor project organizations of any size have designated chief 
engineers (generally called Project Engineer). The project manager relies 
heavily on his chief engineer for detailed engineering work and technical 
judgements concerning himself with overall decision making involving not only 
engineering but schedule, cost, contract and change negotiations, production, 
quality, and customer relations. 

The NASA project manager in effect has many engineers, but no chief 
engineer. Some individual may, by virtue of his personality or stature, 
take on the responsibilities of a chief engineer, but there is no formal 
structure of this kind, nor does the "acting chief engineer" remain the 
same person for the life of the project. 
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5. Contractor program managers tend to delegate more authority to 
their staffs than do the NASA managers* The reasons are to be found in 
the traditional patterns of industrial management compared to the more 
academic atmosphere of NASA. Industrial management holds delegation of 
authority to be an important characteristic of good management. 

6. It could be predicted from observations 4 and 5 that NASA managers 
tend to engage in greater amounts of technical detail than do the contractor 
managers. Indeed, this has been found to be the case, as was pointed out in 
earlier references, particularly with regard to the MSC management style. 
Contractor managers, it was shown, depend heavily upon their chief engineers 
for technical detail, because there is a formal staff structure and because 
the managers themselves have decision making responsibility in many different 

areas . 

7. The prime contractor is a middle man with respect to sub-contractors; 
that is, he is both contractor and contractee. This position can create 
certain problems which the NASA managers do not encounter with their single 
outside interface. Of course, it is also true that NASA managers do assume 
active relationships with many sub-contractors. But these relationships . are 
different from those of the prime contractors, because NASA does not have 
the authority to issue directions to a subcontractor. Informally* though, 
NASA resident and center personnel do interact directly. 
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LIST OF INTERVIEWEES 
NASA HEADQUARTERS, WASHINGTON, D. C. 


Alibrando, Alfred 

Barber, Godfrey E. 

Behun, Michael 
Bingman, Charles 

Bogart, Lt. Gen. Frank A. 
USAF (Ret.) 

Carulli, Len 

Chapman, Richard 

Cohen, Nat 

Constantino, Jim 

Cramer, Jack V. 

Diller, Dick S. 

Duggan, Jack 
Emme, Eugene 
Flint, Walter 
Foster, Willis 
Francis, Lebert 
Gay, Clarence C. 

Gessow, Alfred 
Greenglass , Bert 

Hage, George H. 

Holmes, Jay 
Kinney, Col. Arch 
Krulwich, Lewis J. 


- Public Affairs Officer 
Office of Manned Space Flight 

- Chief, Research and Development Branch 
Resources and Analysis Division 

- Spacecraft Test, Apollo Test 

- Special Assistant to Associate Administrator 
of Office of Organization and Management 

- Deputy Associate Administrator (Management) 
Office of Manned Space Flight 

- Office of Management Development 

- National Academy of Public Administration 

- Management Development Section 

- O.M.S.F. 

- Legislative Liaison Officer 
Office of Legislative Affairs 

- Checkout, Apollo Test 

- PMIS 

- NASA Historical Office 

- Apollo Action Center 


- Spacecraft Test, Apollo Program Office 

- Ass't. Dir. Physics & Math., Research Division 

- Acting Management Systems Division Director 
Office of Technology Utilization 

- Deputy to Apollo Program Manager (Gen. Phillips) 

- Technical Staff, OMSF 

- OMSF, Apollo Advanced Planning Group 

- Deputy Chief , Resources Control 
Apollo Pfogram Controls 

- Program Control, OMSF 


Kubat, Jerry 


NASA HEADQUARTERS > WASHINGTON, D. C. (Cont'd. I 


Liebermann, Carl R. 

Lilly , William E. 

Low, Dr. George 
Newman, Charles T. 
Nolan, Jim 
Poore, Ernest W. 

Preacher, Bert 
Roth, Gilbert Lee 
Seaton, Donald E. 
Skaggs, James B. 
Smolensky, Stanley M. 
Stephens, Richard 
Sullivan, Edward 
Webb, James E. 


- Program Planning, Apollo Program Control 
Acting Chief 

- Assistant Administrator 
Office of Administration 

- Acting Administrator, NASA 

- Resource Analysis Division, Deputy Director 
_ office of Management Development 

- Research and Development Branch 
Research Analysis Division 

- Director, Cost Reduction Program 

- Apollo Configuration Management 

- Chief, Program Integration and Reports 

- Program Control Office 

- Office of Assoc. Administrator for Policy 

- University Affairs 

- Apollo Data Management 

- Former Administrator 

National Aeronautics and Space Administration 


Fulton, James G. 
Miller, George P. 
Teague, Olin E. 


- The Honorable, of Pennsylvania 
Subcommittee on Manned Space Flight Committee 
on Science and Astronautics U.S. House of Rep. 

- The Honorable, of California, Chairman, 
Committee on Science and Astronautics, 

U. S. House of Representatives 

- The Honorable, of Texas 

Chairman, Subcommittee on Manned Space Flight 
and NASA Oversight Subcommittee, Committee on 
Science and Astronautics, U. S. House of Rep. 


MANNED SPACEFLIGHT CENTER, HOUSTON, TEXAS 


Battey, R. V. 

Bo lender. Brig. Gen. C. H. 
Bradford , W . C . 


- Assistant Chief, LM Engineering 

- Manager, LM 

- chief, Checkout System Branch 
Engineering and Development Directorate 
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MANNED SPACEFLIGHT CENTER. HOUSTON, TEXAS (Cont'd,) 


Carson, Maurice 
Cohen, A. 

Faget, Maxime A. 

Farmer, N. B. 

Freitag, Robert F. 

Gardiner, Robert A. 

Gilruth, Robert R. 

Hood, Robert C. 
Kleinknecht, Kenneth S. 
McBarron, J. W. 
McClintock, J. C. 
McDivett , James A. 
Morris, Owen G. 

Nebrig, Dan 
Presnell, John 
Shannon, James J. 
Slayton, Donald K. 
Small, John W. 

Weiss, S. P. \ 

\ 

Young, Wayne 


“ Chief , Portable Life Support System 

- Chief, CSM Project Engineering Division 
Asst* Chief CSM and Integration Engineering 

" Director, Engineering & Development 

- Subsystem Manager 

CM and LM, R&D Instrumentation 

- Director, Manned Space Flight Field Center 
Development 

- Assistant Director for Electronics Systems 
Directorate of Engineering and Development 

- Center Director 

- Chief , CSM Contract Engineering Branch 

- Manager, CSM 

- Apollo Space Suits 

- Chief , Program Control 

- Manager, ASPO 

- LM Project Engineering Division 

- Project Engineer, CSM 108 

“ LM Project Engineer (Vehicle Manager) 

“ LM Contract Engineering Branch 

- Director, Flight Crew Operations 

- Manager, Lunar Surface Project Office 
Directorate of Science and Applications 

- Subsystem Manager - LM Reentry and Descent 
Structure Subsystem 

- Program Control 


MARSHALL SPACE FLIGHT CENTER, HUNTSVILLE . ALABAMA 


Abraham, Ron 
Aden, Robert 
Andressen, Christian 
Blevins, Calvin B. 
Bostwick, Leonard C. 
Bucher, G. 


- Subsystem Manager - S-],C Instrumentation 

- R-ASTR-ES 

- Planning & Resources Office 

- Chief, Engineering Branch, S-lC Stage 

- Deputy Manager, F-l Engine Project 

- Deputy Associate Director for Science 








MARSHALL SPACE FLIGHT CENTER. HUNTSVILLE, ALABAMA (Cont'd.) 




j Bramlet, James B. 

- Deputy Manager, Saturn V Program Office 

Bridwell, Gene P, 

- S-II Subsystem Manager, Propulsion, and 
Acting Chief, Engineering Group 

Birdwell, Porter 

- 1 -V-S-II (Propulsion Subsystem Manager) 

t Brown, R. 

- Chief, Program Control, Engine Program 

Burks , Alfred 

- I-E-MGR 

Clark, Adrian 

- Project Engineer, S-1C-R&D0 

Cook , Richard 

- Deputy Director of R&DO 

Crossman, Robert L. 

- Chief, Contracts Management Branch, 
Contracts Office 

DeNeed, Carl 

- I-PL-MGR 

y Dodd 

- Test Laboratory 

Drummond, Floyd M. 

- Manager, Airlock Module, AAP 

Duerr, Friedrick 

- Manager IU Stage 

; - Dunlap , Porter 

- Manager, Group Support Equipment - AAP 

-V Farish, P. T. 

- Manager, Systems Safety 

Ferrell , Toon 

- I-E-J 

Foster, Jay 

- Executive Staff 

Fritz* Carl 

- Program Development 

!#, Fuhrmann, Herbert W. 

l ‘ -sfci 

- Branch Chief, Mechanical Systems Branch 
Propulsion Division, P&VE Laboratory 

^ Godfrey , Roy 

- S-IV-B Project Manager 

; Griner, Robert F. 

\ 

- i 

i=-' 

- S-IV-B Project Engineer, Systems Engineering/ 
Project Office, P&VE Laboratory 

; Haenish , Hilmar 

- Apollo Applications Program Office 

Hagen, William A. 

- Executive Staff 

: Hallisey, Harold W. 

- Chief, Project Control Branch, S-1C Stage 

Hughes, Ned 
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